Is it correct to assume that the X1-X2 cross-signed root, expiring next year, will no longer be renewed? As it will not be used anymore in any of the upcoming chains.
We haven't yet made a determination whether or not to renew the x2-by-x1 cross-sign. Do you have any input on whether or not that would be valuable to you?
(this is an interesting topic, so I've split it to its own thread)
4 Likes
Not for me, no. The direct X1- or X2-to-intermediate chains are shorter and cleaner.
Although it does take away an option you once listed as an advantage back when the cross-signed root was created, namely that clients trusting X2 can build a shorter ECDSA-only path for faster validation (simply ignoring the X1-X2 cross-sign), now they will have to go via X1, involving RSA. While that same chain was providing compatibility for clients not yet trusting X2, going via X1. Not sure if that's really enough of an advantage to worry about though. Personally I'm not concerned.
5 Likes
Yeah, fundamentally the question is: are there websites that want to pay the cost of serving a longer chain to all of their visitors, in return for a subset of those visitors (the ones who trust X2) being able to perform a faster ECDSA-only validation of that chain?
When we first issued X2, I think it made a lot of sense to cross-sign it. That's a way of saying "this root will be widely trusted eventually, but for now there's also a cross-sign to fall back on". Now, X2 is widely trusted (by updated systems), and folks who want to live in the modern era can serve a short, ECDSA-only chain that terminates at X2. But for folks who still want wider compatibility by terminating at X1... the chain they serve is going to contain one RSA signature no matter what. Why force them to also serve an entire extra certificate alongside it?
3 Likes
I copy here my comment from the Lounge, there it was an off topic, here it is on topic.
4 Likes
For browsers specifically, I believe they typically cache (or even ship) trusted intermediates, so they avoid full chain validation anyway once they have seen and validated the new E5 and E6 intermediates once?
5 Likes
The question then becomes, when will X2 be trusted widely enough to switch to that ECDSA-only chain - both for individual site administrators to change their own config for their specific audience, and for LE to make it a default at some point. The problem with that is, unlike TLS protocols and ciphers where you can see what your clients support in their SSL hello, you have no visibility on their trust stores to base such decision on (other than guesstimates based on User Agents or other client identifiers).
7 Likes
Well X2 just entered trust store on android 14, and seeing what happened before I guess at least 2030,7 years later?
3 Likes
You don't really have those either, since you have to make a decision on what certificate to send after having only seen:
- The client's IP address
- The clients TLS ClientHello message (including ciphersuites and other supported algorithms, but no HTTP-style user agents)
You can try to "fingerprint" the ClientHello, but the problem here is that Android's TLS stack is just BoringSSL, so you can't really narrow it down much.
6 Likes
BoringSSL is an open source project, but it is not intended for general use...
3 Likes
But it's used in basically all Android versions, plus Chrome+Chromium, Chromium-based browsers (so like all of them, except Firefox and Apple) and more. So knowing "that client is BoringSSL" doesn't even tell you the operating system or environment you're communicating with.
5 Likes
I am going through a few things, and am confused.
-
The image on the Key Ceremony post suggests to me that X1 has cross signed X2. Am I reading this wrong, or should this be updated to remove that top line? https://letsencrypt.org/2024/04/12/changes-to-issuance-chains
-
I never noticed how short-lived the cross-sign is. I assume that is due to CA/B forum rules?
-
I don't have much of an input on the utility of keeping this around, but I wonder if there may be a compromise in which the key is generated and appears on the Certificates page as a downloadable option... but is not offered through ACME as an alternate chain. That could allow subscribers who want to explore deploying this chain the opportunity to do so – but only through manual intervention.
5 Likes
Yes, the image is somewhat of a hybrid between preexisting signatures and signatures that were actually produced during the ceremony. The cross sign from X1 to X2 does exist, but was produced in 2020, not this year.
CA/BF rules do limit the lifetime of a Subordinate CA Certificate, but we limit ourselves further. IIRC, we gave it the same lifetime as the other intermediates generated during the same ceremony, because fundamentally that's what it is: an intermediate.
Agreed that this is the only way we would do it. As I mentioned earlier, offering the rooted-at-X1 long chain is not very useful at the ACME layer, because many clients cannot distinguish between chains with the same topmost certificate. The question is whether we should even go this far.
6 Likes
I think this only matters to us.
In an ideal world, we'd have intermediates with both signatures instead of two different E5s. I have no idea if x509 even supports that.
3 Likes
If there isn't going to be a X2-by-X1 cross-sign and there is an alternative chain with just X2, it's probably a good idea to get Certificate Compatibility - Let's Encrypt up to speed and update it to the current status.
For future reference, some links with sources:
https://android.googlesource.com/platform/system/ca-certificates/+/a7f7f25981bbb3a032109c92d1e5370aa6719020
5 Likes
I wasn't talking about "real time" certificate selection here, but about the decision (for an individual admin) to switch from an X1-rooted chain to an X2-rooted one, based on logs or other statistics.
5 Likes
I mean, if you listen to what cloudflare's been saying... Let's Encrypt is literally a bleeding edge legacy-be-damned CA.
And that's fine, I guess, if you want to use X2 by default.
4 Likes
A little bit offtopic perhaps here, but the image makes a clear distinction between certificate & private key, which makes sense, because it's in fact the private key being the (signing) trust anchor. However, what I don't understand so much is why there's only a single certificate logo per private key whereas cross-signed certs should deserve (IMO) their own separate certificate? Otherwise it would defeat a little bit the purpose of separating the private key from the certificate to begin with.
3 Likes
Thanks for all the clarifications.
If the cross-sign had been re-signed this year (which I interpreted from the image), I would advocate to keep publishing it for manual “off-label” use.
Considering it was not re-signed and expires next year, that really changes things. Continuing to offer it, even for experimental usage, risks an expectation/reliance by an expectedly tiny population to have it re-signed — which could require the costs/labor/overhead of a dedicated key ceremony (vs the incidental/negligible costs of doing this during another budgeted/planned key ceremony). That really changes things, as a “no effort” experimental support runs the risk of costly support expectations for a tiny group. This makes me solidly against keeping it around as-is.
If any weird issues pop up on the forums where it could be useful, I think the people here could just point to a non-linked location on the website or websites’ GitHub repo (which should have it in an old tag).
imho, it would be neat if there were a “retired certificates” page on the site that has all the expired and retired certificates for research and testing use. This cert, and a few others, could just sit there. It would be available for experimental usage until expiry, but no support would be expected or suggested.
8 Likes
Ouch. Cloudflare says they request 1 million certs / day in that article. And, probably most of those will no longer be from LE.
I'm sure there will be some loss outside of Cloudflare too. LE currently around 4 million certs / day so I will be watching the stats as the year progresses.
Dropped DST along with new intermediates and new geographic authentication farms makes for a volatile year.
5 Likes