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

[Andreas Steffen]

Hello,

that the presence of the EC PARAMETERS section breaks the parsing
of a PEM-encoded ECC key is a well known problem. Our PEM-to-DER
converter just is not aware of the payload type it is converting
and cannot handle multiple payloads in a PEM-file.

We recommend to use our ipsec pki --gen tool

  http://wiki.strongswan.org/projects/strongswan/wiki/IpsecPkiGen

which with the arguments --type=ecdsa and size=256|384|521 generates
only those curves allowed for IKE use by the ECDSA RFC 4754

  http://tools.ietf.org/html/rfc4754

With a recent strongSwan version the ECDSA key and certificate files
can even be stored in PEM format.

Regards

Andreas

On 12/01/2010 04:36 AM, Jan Willem Beusink wrote:
> 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

======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==