Project

General

Profile

Issue #3257

Unable to parse letsencrypt ecdsa private key

Added by Glen Huang 7 days ago. Updated 2 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.8.1
Resolution:

Description

I have these plugins loaded

charon pkcs11 nonce x509 pkcs1 pkcs7 pkcs8 pkcs12 pem openssl kernel-netlink socket-default vici eap-identity eap-mschapv2 eap-tls

And the letsencrypt ecdsa private key has the format of

-----BEGIN EC PARAMETERS-----
xxxx
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
xxxx
-----END EC PRIVATE KEY-----

I put the key file in ecdsa folder (private also tried), and strongswan complained "building CRED_PRIVATE_KEY - ECDSA failed, tried 4 builders"

Did I miss some plugins? How should I load letsencrypt ecdsa private key?

History

#1 Updated by Tobias Brunner 7 days ago

  • Status changed from New to Feedback

Did I miss some plugins? How should I load letsencrypt ecdsa private key?

You have to remove the params. The pem plugin only supports a single -----BEGIN...-----END... section per file and it doesn't do anything with those params.

#2 Updated by Glen Huang 7 days ago

Does that mean I shouldn’t use fullchain.pem where it contains multiple certs?

If the chain is long and strongswan only sends the last one, will client reject it if it only trust the top ca and doesn’t know intermediate ones?

#3 Updated by Tobias Brunner 7 days ago

Does that mean I shouldn’t use fullchain.pem where it contains multiple certs?

It will only parse the first one, so depends on the use case and the order in the file. Generally it won't work, i.e. you need separate files for the (intermediate) CA certs and the end-entity cert.

#4 Updated by Glen Huang 2 days ago

Tobias Brunner wrote:

Does that mean I shouldn’t use fullchain.pem where it contains multiple certs?

It will only parse the first one, so depends on the use case and the order in the file. Generally it won't work, i.e. you need separate files for the (intermediate) CA certs and the end-entity cert.

I think my confusion comes from this mental model:

The certificate chain is like this

CA -- signs --> intermediate -- signs --> end entity

Clients trusts CA, and server is sending end entity cert to authenticate itself.

Now the question is, what role does intermedia play here?

I tried making charon load intermediate cert also. Upon establishing the connection, I checked the IKE_AUTH response content, only the end entity cert was sent. Without intermediate cert, I wonder how could the client authenticate the server with only the trusted CA?

Is the intermedia cert redundant?

#5 Updated by Tobias Brunner 2 days ago

  • Category set to configuration

Is the intermedia cert redundant?

No, it is usually sent by the server (it could be installed on the client, then only the server certificate would have to be sent, but usually only the root CA is installed). If it's not sent, you configured something incorrectly (i.e. wrong intermediate cert, or it's not loaded), check the log and status output.

#6 Updated by Glen Huang 2 days ago

Tobias Brunner wrote:

Is the intermedia cert redundant?

No, it is usually sent by the server (it could be installed on the client, then only the server certificate would have to be sent, but usually only the root CA is installed). If it's not sent, you configured something incorrectly (i.e. wrong intermediate cert, or it's not loaded), check the log and status output.

Ah, I put in the wrong cert, so it didn't work. Now I can see strongswan is correctly returning both intermediate and end entity certs. Thanks for the help!

But things still don't quite square. It's more about iOS's configuration profile. Not sure if it's ok that I ask here:

I try to be a good citizen and make iOS send a CERTREQ by specifying ServerCertificateIssuerCommonName in the profile (it's actually required by the iOS's profile reference). But puting either CA's CN or intermedia cert's CN, it won't send CERTREQ (it complains something like: ikev2_crypto_copy_remote_certi:1727 BACKTRACE failed to retrieve remote CA cert data by CN (DST Root CA X3)), and in this case, even if I ask charon to always return certs, it won't connect successfully (IKE_AUTH response is returned, but client fails with:

ikev2_crypto_remote_cert_and_s:3160 remoteCertAuthorityArray missing from config
ikev2_ike_auth_initiator_recei:259  Certificate authentication data could not be verified

If I don't specify ServerCertificateIssuerCommonName, and ask charon to always return certs, it can connect.

If I manually import server's end entity cert into iOS client's keychain, and specify server's CN in ServerCertificateIssuerCommonName, it sends CERTREQ, and can connect. In this case, I don't have to ask charon to always return certs, and the intermediate cert becomes redundant (the case I was reporting).

So does that mean, iOS won't look for certs in the system keychain when trying to find the cert correspond ServerCertificateIssuerCommonName, and omitting it is the only correct choice?

#7 Updated by Glen Huang 2 days ago

Just to make sure I understand the RFC right. CERTREQ should contain sha1 hashes of trusted CA's public keys right? So in this case, the client should contain DST Root CA X3's public key sha1 hash in CERTREQ, and not that of the intermediate cert?

#8 Updated by Glen Huang 2 days ago

iOS won't look for certs in the system keychain.

That seems to be the case, I just manually import DST Root CA X3's certificate, and now it can connect. So system keychain is ignored.

Looks like I HAVE to omit ServerCertificateIssuerCommonName?

Also available in: Atom PDF