starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-09-04 17:07:24 +02:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

Certificate file also contains chain for ACME v2 #299

New Issue
Closed
opened 2025-12-29 01:21:27 +01:00 by adam · 7 comments
adam commented 2025-12-29 01:21:27 +01:00
Owner
Copy Link
Copy Source

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
adam commented 2025-12-29 01:21:28 +01:00
Author
Owner
Copy Link
Copy Source

@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).
adam commented 2025-12-29 01:21:28 +01:00
Author
Owner
Copy Link
Copy Source

@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.
adam commented 2025-12-29 01:21:28 +01:00
Author
Owner
Copy Link
Copy Source

@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?
adam commented 2025-12-29 01:21:29 +01:00
Author
Owner
Copy Link
Copy Source

@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`
adam commented 2025-12-29 01:21:29 +01:00
Author
Owner
Copy Link
Copy Source

@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.
adam commented 2025-12-29 01:21:30 +01:00
Author
Owner
Copy Link
Copy Source

@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.
adam commented 2025-12-29 01:21:30 +01:00
Author
Owner
Copy Link
Copy Source

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#299