Certificate file also contains chain for ACME v2 #299

Closed
opened 2025-12-29 01:21:27 +01:00 by adam · 7 comments
Owner

Originally created by @mvistein on GitHub (Mar 13, 2018).

The certificate retrieved from Let's Encrypt ACMEv2 endpoint (both staging and production) contains both the end certificate and the intermediate certificate (which is conforming to 7.4.2 of the ACME draft). As a result, now the fullchain.pem file contains the intermediate certificate twice.

Originally created by @mvistein on GitHub (Mar 13, 2018). The certificate retrieved from Let's Encrypt ACMEv2 endpoint (both staging and production) contains both the end certificate and the intermediate certificate (which is conforming to 7.4.2 of the ACME draft). As a result, now the fullchain.pem file contains the intermediate certificate twice.
adam closed this issue 2025-12-29 01:21:27 +01:00
Author
Owner

@thias commented on GitHub (Mar 14, 2018):

Also worth noting is that the intermediate certificate included in the cert-<id>.pem file seems to have Windows EOL, while the certificate above has proper UNIX EOL, so there a newline type mix in the file (this is on RHEL7).

@thias commented on GitHub (Mar 14, 2018): Also worth noting is that the intermediate certificate included in the `cert-<id>.pem` file seems to have Windows EOL, while the certificate above has proper UNIX EOL, so there a newline type mix in the file (this is on RHEL7).
Author
Owner

@cpu commented on GitHub (Mar 14, 2018):

Also worth noting is that the intermediate certificate included in the cert-.pem file seems to have Windows EOL

@thias I think this is a mistake on the Let's Encrypt side. I opened https://github.com/letsencrypt/boulder/issues/3557 to track fixing this.

@cpu commented on GitHub (Mar 14, 2018): > Also worth noting is that the intermediate certificate included in the cert-<id>.pem file seems to have Windows EOL @thias I think this is a mistake on the Let's Encrypt side. I opened https://github.com/letsencrypt/boulder/issues/3557 to track fixing this.
Author
Owner

@lukas2511 commented on GitHub (Mar 14, 2018):

Whoopsie. The easiest solution for this would be to just completely ignore the old chain.pem and just write the certificate directly to fullchain.pem, but that may break some setups...
I'll need to figure out how to extract just issuer certificates from a file with multiple certificates... I guess since they are in order I could just sed and grep my way to those certificates, but does anybody know a cleaner way?

@lukas2511 commented on GitHub (Mar 14, 2018): Whoopsie. The easiest solution for this would be to just completely ignore the old `chain.pem` and just write the certificate directly to `fullchain.pem`, but that may break some setups... I'll need to figure out how to extract just issuer certificates from a file with multiple certificates... I guess since they are in order I could just sed and grep my way to those certificates, but does anybody know a cleaner way?
Author
Owner

@mvistein commented on GitHub (Mar 14, 2018):

I think you could just process the file using the openssl x509 module.

On my system (version 1.0.2g) the following command yields the right result:

openssl x509 -in cert.pem -out cert2.pem

@mvistein commented on GitHub (Mar 14, 2018): I think you could just process the file using the openssl x509 module. On my system (version 1.0.2g) the following command yields the right result: `openssl x509 -in cert.pem -out cert2.pem`
Author
Owner

@lukas2511 commented on GitHub (Mar 14, 2018):

Should be fixed with 2533931cf1, thanks for reporting this issue.

@lukas2511 commented on GitHub (Mar 14, 2018): Should be fixed with 2533931cf1311e33252bc2492975afae71bd447f, thanks for reporting this issue.
Author
Owner

@cpu commented on GitHub (Mar 14, 2018):

Also worth noting is that the intermediate certificate included in the cert-.pem file seems to have Windows EOL, while the certificate above has proper UNIX EOL, so there a newline type mix in the file (this is on RHEL7).

@thias This is fixed and should be consistently UNIX newlines now. Thanks for flagging it.

@cpu commented on GitHub (Mar 14, 2018): > Also worth noting is that the intermediate certificate included in the cert-<id>.pem file seems to have Windows EOL, while the certificate above has proper UNIX EOL, so there a newline type mix in the file (this is on RHEL7). @thias This is fixed and should be consistently UNIX newlines now. Thanks for flagging it.
Author
Owner

@thias commented on GitHub (Mar 19, 2018):

@lukas2511 @cpu : Thanks for the quick fixes. Let's Encrypt with wildcard certificates rocks! Thank you sooo much for your great work on your respective projects, it's MUCH appreciated.

@thias commented on GitHub (Mar 19, 2018): @lukas2511 @cpu : Thanks for the quick fixes. Let's Encrypt with wildcard certificates rocks! Thank you sooo much for your great work on your respective projects, it's MUCH appreciated.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#299