[strongSwan-dev] charon: 00[LIB] building CRED_PRIVATE_KEY - ECDSA failed, tried 3 builders --> solution

Jan Willem Beusink beusink at gmail.com
Wed Dec 1 04:36:08 CET 2010


Hi all,

Trying to get strongswan going I ran into a problem and was able to solve
this. I'd like to share my findings.



=== Keeping it short, ===
I went from "no private key found for 'C=NL, O=etc.'"  to "charon: 00[LIB]
building CRED_PRIVATE_KEY - ECDSA failed, tried 3 builders" to the openssl
command.

Turns out that: "openssl ecparam -out hostB_ECC_Key.pem -name secp384r1
-genkey" does not work, but "openssl ecparam -out hostB_ECC_Key.pem -name
secp384r1 -genkey -noout" does. The difference being the "-noout" option.

Although this solves my problem, I would like to suggest (see below) a
simple fix applied to master to provide a more general solution.



=== The long version: === 
I tried to get a strongswan setup going. Getting "no private key found for
'C=NL, O=etc.'"  when trying to start up a connection.

In the /var/log/syslog log file I found that the problem lied in the loading
of the private key:
Dec  1 01:41:07 althor charon: 01[CFG] loading secrets from
'/usr/local/etc/ipsec.secrets'
Dec  1 01:41:07 althor charon: 01[LIB] building CRED_PRIVATE_KEY - ECDSA
failed, tried 3 builders
Dec  1 01:41:07 althor charon: 01[CFG]   loading private key from
'/usr/local/etc/ipsec.d/private/hostB_ECC_Key.pem' failed

First I thought I misconfigured the ipsec.secrets file, as that didn't pay
off I started googling. So I tried to adjust the strongswan.conf load
directive under charon as suggested in
https://lists.strongswan.org/pipermail/users/2009-May/003456.html. I even
removed the directive, resulting in an impressive loading list: "loaded
plugins: aes des sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem
openssl fips-prf xcbc hmac attr kernel-netlink socket-default stroke updown
resolve" But the error was still there.

At this point I realized that it probably wasn't the configuration. I
remembered reading something about strongswan supporting only several ECC
curves. I figured, hey maybe something is wrong with the implementation of
this curve, let's try another. So I searched for 'openwrt secp521r1' and got
only one hit. Writing this I realize that searching for openwrt was not what
I intended, must be sleep deprivation...

Anyway, in this export of the wiki site, I found an example and followed it.
Trying, what I thought was, a different curve (it was the same, another sign
I should be sleeping right now) which worked! Thinking I discovered a bug, I
compared the curves. These were as I stated before the same, so I started to
look closely at the command options. Turns out to be the -noout option... As
I wondered why this would break the reading of the key file I started
digging again:

openssl ecparam [options] <infile >outfile
where options are
<snip>
 -noout            do not print the ec parameter
 -text             print the ec parameters in text form
<snip>

user at althor:/tmp/certificates$ openssl ecparam -name secp384r1 -genkey
-----BEGIN EC PARAMETERS-----
BgUrgQQAIg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDBT3cCxjn+JwMXCESVzdsEQ2/tTG/jyVLjI6XIBhODQ7ZXr1Bqf9Djz
+ZUituuut1egBwYFK4EEACKhZANiAATitR5HNfn8E3wEQFLSm7nM2XdUZZ/kWcUC
uAsTdKhC8X94bd7+j4+1Cl8V8oFcqbW9yuF9wm4swue/MUmBBS/iQxuyS1nMn0Az
P7nKm+cbCM1G6xX+Pg0b+acnsrEZ+n4=
-----END EC PRIVATE KEY-----
And
user at althor:/tmp/certificates$ openssl ecparam -name secp384r1 -genkey
-noout
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDCZ3BoZKIvC/neiUjsxVFZlXzHcl8omBIfcpoLYppMx01FPSwRNBkIb
6sALwxky9tigBwYFK4EEACKhZANiAAT8CAs370Ogo9muS1TSMVCZOM2qCabqlhB+
kJpOsPx9ZvYEDJhHeNE38hY/76Es1hb/e6Vk4Jj8+vYkL+4adhGc+H310wN6g05l
T9W3nuZFLUZ8C5fFASlWoYxC7/W+iIo=



=== Suggestion: ===
I don't know if it's the plugin or strongswan itself, but I find it strange
that strongswan cannot handle this. I was thinking that a simple fix could
be applied to master? For example that strongswan skips the part before
'-----BEGIN EC PRIVATE KEY-----'. This would also fix the -text command
option if someone were to use this.


Kind regards,

Jan Willem Beusink





More information about the Dev mailing list