add acme-preferred-chain config key #864
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the deprecation of DST X3 root CA, which used to sign Let's Encrypt root CA, a few issues raised and can be summarized as:
DST X3
, clients that hasDST X3
on their trusted CAs bundle, care about the expiration of their CAs, and a somewhat old openssl, will fail to trust in the Let's Encrypt chain even if they trust in the Let's Encrypt'sISRG Root X1
. Clients should update openssl or removeDST X3
from their trusted CAs. This is the default chain provided by Let's Encrypt;ISRG Root X1
, which is Let's Encrypt's root CA, old clients will fail to trust Let's Encrypt certificate, mostly Android older than 7.1.1.Let's Encrypt production API adds alternative chains that can be chosen by the Common Name of its topmost certificate. This is the purpose of this configuration key, so sys admins can choose the chain that will have the lesser impact on their users.
Acme client was updated in a way that a mistyped preferred chain doesn't fail the emission of the certificate, which avoids to being blocked by the acme server due to the amount of new orders.
As a first implementation that's being planned to be merged to v0.13, it wasn't added the ability to identify that a preferred chain was changed. Such change would need to change even more code, making this even less secure to be merged to a stable version.
Should be merged to v0.13 so users can benefit from this alternative as soon as possible.