Obviously, this is an early stage of my idea. I am bringing this up now, and tagging several client authors, in the hopes you will be interested in collaborating on both a proposal to LetsEncrypt and eventually an RFC to the ACME working group.
cc: @rmbolger @webprofusion @mholt @_az @Neilpang @griffin
--
I propose a new endpoint is added to the /directory
to list the currently available chains for a client/subscriber.
Why?
A client must know which chains are offered in order to select a "preferred chain", however the current ACME spec doesn't surface this information until an order is finalized โ and at that point the chains would need to be downloaded and analyzed to present options. While this information may be found on websites and through internet searching, it fails on the following points needed for streamlined automation:
- It is not available in a standardized machine readable format from any ACME powered CA.
- It is not available in a standardized format that is used by multiple CAs
- In LetsEncrypt's current service, this information can vary across accounts. [e.g. LetsEncrypt accounts are currently locked to either the X1 (default) or X2 (opt-in) chains].
Additionally, in the near future, LetsEncrypt has scheduled the following two actions:
- Switching of the default and alternate chains
- Retirement of the DST X3 chain
The current ACME spec is deficient in features that could be used to better automate certificate procurement in light of the above, and also handle situations in which default chains switch.
As a Client Author and ACME Subscriber, there is a need to query a server to determine the possible roots before procuring a Certificate. While a best-practices Client can (and should) download all chains - or offer the ability to easily switch/rebuild chains after download - adhering to such practices would not address scenarios such as the "X2 opt-in list" wherein a certificate could be procured using an unintended root/chain.
Aside from the immediate benefit to consumers of allowing them to query the available chains/roots, this would influence the standardization of how all clients handle chain selection. Currently (and historically), clients have used their own logic to handle chain selection โ relying not just on different methods, but also different fields or information extrapolated from the chains/certificates. Some have used Issuers, Common Names, fingerprints or other methods. If the ACME spec were extended to present possible chains in a structured manner, Clients would expectedly have their logic influenced by this and rely on these fields.
An endpoint such as this would also allow for programmatic detection of the change in available or default chains โ which clients could then surface to end users.
A formal specification could also state the logic compliant clients utilize. The most "official" guidance on this topic I've been able to find comes from LE's Aaron Gable in an Issue and PR against Certbot [See Providing different alternate chain selection methods ยท Issue #8577 ยท certbot/certbot ยท GitHub], and in that discussion we can see some great points.
Below is a potential format for an availableChains
JSON object.
- A key is created for every Type of the EndEntity/Leaf Certificate
- a "_default" key indicates the default chain by Type and Position.
- The value is a List of Certificates in the chain:
- the 0 element is the Root, followed by the intermediates
- Each element is a list in the format of: Common Name, Issuer, URL, Expiry, Type
{
"availableChains": [
"RSA": [
[["DST Root CA X3", "DST Root CA X3", "", "September 30, 2021", "RSA"]
["ISRG Root X1", "DST Root CA X3", "https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem", "September 30, 2024", "RSA"]
],
[["ISRG Root X1", "ISRG Root X1", "https://letsencrypt.org/certs/isrgrootx1.pem", "June 4, 2035", "RSA"],
]
],
"ECDSA": [
[["ISRG Root X1", "ISRG Root X1", "https://letsencrypt.org/certs/isrgrootx1.pem", "June 4, 2035", "RSA"],
["ISRG Root X2", "ISRG Root X1", "https://letsencrypt.org/certs/isrg-root-x2-cross-signed.pem", "September 15, 2025", "ECDSA"]
],
[["ISRG Root X2", "ISRG Root X2", "https://letsencrypt.org/certs/isrgrootx2.pem", "September 17, 2040", "ECDSA"],
]
],
"_default": ["RSA", 0],
}
I stress: this is an early stage idea. This has been annoying me since the various default chain switches during the DST expiry. About a week or two ago, I realized a new account-specific endpoint is needed. I am not sure about the output (though I offer a suggestion) or the input (should a listing of domains be posted in the payload because it could affect the possible chains?)