The above page lists two certificate chain names ("DST Root CA X3" and "ISRG Root X1"). Can someone clarify which of these corresponds to the "long" chain which includes an intermediate ISRG Root X1 certificate, and which one corresponds to the "short" chain which does not include it?
I have been looking for this info in the documentation, but cannot find it.
Sorry but still not clear to me. That page lists "root certificates" and "intermediate certificates" but does not seem to identify the actual chains or at least not with the same names as listed in acme.sh's GH page. This may be obivous to someone familiar with the matter but it certainly is not obvious to me...
Perhaps you're looking at the staging chain names on the acme.sh page? Because those are indeed not listed on the chain page of the Let's Encrypt documentation, for obvious reasons. If you scroll a little bit further on the acme.sh page, you'll see the production environment chains and those names will correspond to the certificate names in the Chain of Trust documentation page.
Also, if it wasn't yet clear: on the Chain of Trust documentation page, you can follow the lines yourself to determine what the "short" and "long" chain is.
In the Chain of Trust documentation page I don't see names of chains anywhere. If I am supposed to extract that from the diagram, then I am failing at that. Also the page lists names of root certificates, but one is "ISRG Root X1" (which matches one of the chain names) and the other one is "ISRG Root 2" (which doesn't) so again this doesn't help.
If you draw a line from one of the trust anchors to a subscriber certificate, which line is short and which line is long? Yellow or blue?
If you don't fully grasp the concept of a certificate chain, please see the glossary: Glossary - Let's Encrypt
Also, if the documentation of acme.sh with regard to their --preferred-chain option, please open a support ticket with acme.sh. It's an ACME client without any connection to Let's Encrypt. It even uses a completely different, commercial CA by default and not Let's Encrypt.
Ah, nice, so one has to resolve a puzzle to find the answer to the question.
I do grasp the concept of a certificate chain, but:
1/ I have a difficult time understanding the diagram. I bet I am not alone.
2/ It was not obvious to me that the chains are named after the trust anchors
3/ It was not obvious to me that these two certs in the diagram actualy represent the trust anchors
4/ It was not obvious to me that in order to play the "which is shorter" game I could only follow the black lines and not the gray ones
(mind you, the glossary doesn't help with any of the above).
Since the chain names are actually part of the API (via the PreferredChain option in the ACME protocol) I think it would be a good idea to explicitly document these.
The diagram presents the named trust anchors in the rectangles with rounded edges, which are actually the private keys. One private key/trust anchor can have multiple certificates associated with it.
The terms "short" and "long" aren't official terms. I don't know where you read these terms, but perhaps that location should have made a better effort of explaining it. The most recent blog post from Let's Encrypt regarding the chains (Shortening the Let's Encrypt Chain of Trust - Let's Encrypt) mentions short and long. While not explaining these terms in detail, one can easily interpret which is what.
They're not. RFC 8555 (ACME) gives ACME servers the option to include multiple chains with a Link: rel="alternate" header when providing the ACME client with the certificate.
How the ACME client parses and presents these alternate chains is up to the ACME client. They're not named by Let's Encrypt nor the ACME protocol.
I actually agree this Long vs Short chain reference is confusing and that the LE chain of trust diagram is not especially clear. The length of chain has nothing to do with validity itself, it's just how they happen to be arranged currently.
I think of them as:
[Leaf] > R3 > ISRG Root X1 > DST Root CA X3 (we have taken to calling this the long chain)
and
[Leaf] > R3 > ISRG Root X1 (we have taken to calling this the short chain)
As an aside, I see on Certificate chain no longer includes ISRG Root X1? - #9 by guillerodriguez you may still have an important dependency on the "long chain" due to old clients not trusting ISRG Root X1 as the root, I would consider using certs from a different CA as the chain with DST Root CA X3 is going away soon (as you probably know) and now would be the time to decide/try out alternatives. Just getting DST Root CA X3 to work again is only a short term fix.
The terms "short" and "long" aren't official terms. I don't know where you read these terms, but perhaps that location should have made a better effort of explaining it.
Also this one: Shortening the Let's Encrypt Chain of Trust - Let's Encrypt refers to "the longer chain" and "the shorter chain" and mentions that "The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request".
They're not. RFC 8555 (ACME) gives ACME servers the option to include multiple chains with a Link: rel="alternate" header when providing the ACME client with the certificate.
I stand corrected. I really thought the alternate links included a "canonical" name chosen by the server, and which could then be used by the clients to select the desired alternate chain. After reading your last post and going through the details of RFC 8555 I see that this is not the case.
I wonder why, though. Wouldn't it make sense for the server to advertise alternate chains with an explicit name? This would make things much easier as the server could then document the names of the available chains, thus providing an unambiguous way for users to specify their preferred chain, which would not depend on the actual client used. With the current spec (where the alternate links do not include a name) each client must come up with their own way to select alternate chains.
How the ACME client parses and presents these alternate chains is up to the ACME client. They're not named by Let's Encrypt nor the ACME protocol.
I understand this now. Sorry for the confusion and thanks for explaining.
As a constructive criticism I would like to say the following:
I still believe the diagram in the "Chain of Trust" page is very confusing for people not familiar with LE's implementation. I'm not sure how to improve that but I can say it is not clear at all for newcomers.
The "Shortening the Let's Encrypt Chain of Trust" post linked above mentions that ACME clients can be configured to request alternate chains but does not provide any further hints on how to do this. This is what confused me in the first place. I think that this could easily be improved by simply mentioning that the way to select this alternate chain is actually client-specific. That would have gotten me on the right track probably.
You should realize that "long" and "short" chain are relative names (relative to each other), pertaining only to the current situation of phasing out the expiring DST Root CA X3 cross-signature.
In the future, LE may offer other alternate chains for other reasons (most likely future Root CA rotations), and the current naming scheme of chains would no longer be applicable at that point. So you wouldn't want to hardcode (and rely on) such "descriptive" names.
You should realize that "long" and "short" chain are relative names (relative to each other), pertaining only to the current situation of phasing out the expiring DST Root CA X3 cross-signature.
In the future, LE may offer other alternate chains for other reasons (most likely future Root CA rotations), and the current naming scheme of chains would no longer be applicable at that point. So you wouldn't want to hardcode (and rely on) such "descriptive" names.
Yes, I realize that.
I was using "short" and "long" terms just as a way to identify them in the context of my original question. What I really wanted to know was "how do I configure my ACME client to request the chain that will remain compatible with Android 7 and earlier once the default changes in Feb 2024". But I phrased that more or less as "how do I configure my ACME client to explicitly request the long chain".
Short term: Stick with LE and configure client to explicitly request the long chain. This buys me some time (until June 2024 instead of Feb 2024)
Mid/long term: Evaluate whether we need to switch to a different CA (most probably that would be ZeroSSL) or announce that we drop support for devices running Android 7 and earlier.
You have bigger issues, in that case. You'll soon need an older root anyway, with the cross-sign expiring. I think gts or sectigo have some.
Pretty much everybody here understands what we're talking about, but it's also a very Let's Encrypt specific bit of knowledge, as roots are not usually cross signed.
