Will clients give an error if the server presents a certificate chain that includes the revoked X2 by X1 cross signed certificate?
I guess the answer is "no", as long as the client trusts the X2 root certificate.
Are there some (perhaps old) clients that won't handle this scenario well?
The X2 by X1 certificate was only used for two purposes.
I'm worried that a naive implementation would always follow the provide chain first and then errors out on the revoked cross sign, never checking if there's another valid path. But I suppose it's unlikely for this mistake to have happened in any important client.
The chain to X2 is also not the default chain, so most ACME setups will just use the still functioning X1 chain and most clients trust X2 directly. However some servers might want to switch to the X1 chain until a new cross sign is created (or maybe the old cross sign will only be revoked after the new cross sign is installed at http://x2.i.lencr.org/).
Ahh, for some reason I thought ECDSA certs were using the X2 <- X1 chain by default. Completely misread the documentation there, it's only the certs that chain to YE that use this cross signed cert.
I wouldn't expect issues in mainstream browsers. They tend to get intermediate updates in a separate way from the browser vendors. (See Firefox's blog post on how they preload all the intermediates by pulling from CCADB.)
Other uses (API calls, Java services, etc.) might be a little more complicated to predict. Way back when DST Root CA X3 cross-signed Let's Encrypt's intermediates, that root had an issue with not updating its published CRL and some systems returned very cryptic errors that took a while to decipher. The thread is actually really confusing since people were conflating issues that SSL Labs reported that were actually on their end, but there were actual error reports sprinkled in there as well.
Preloading intermediates does not exclude those intermediates from being checked for revocation I would hope.
We don't have OCSP anymore, but technologies like Mozilla CRLite are pushing revocations to the browser by other means, based on the CRLs provided by LE. Chrome also checks revocations.
I'm not so sure I'd bet on browsers not checking for intermediate revocations.
What I'm trying to say, though I may be too optimistic about it, is that the browsers would push out the updated intermediates to their users at around the same time as they push out the revocation of the old ones. So even if a server sends out a chain with the revoked intermediate in it, the browser would know that it can use the replaced intermediate that it already knows about instead. At least that's the theory.
Well that depends on the timeline, because as of now there is no updated intermediate. LE has marked the new cross-signed roots as revoked, but according to Certificate Transparency logs no updated intermediates have been issued. The fix LE deployed was to switch everyone back to the old hierarchy, e.g. currently no certificates are being issued under the new hierarchy as no trusted path is available.
Though, it looks like the new cross-signed roots (with the Enhanced Key Usage extension) are already available from the AIA URLs (at least since a few hours), e.g. from http://x2.i.lencr.org/ :
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6c:8f:1d:c7:27:c7:11:7f:7b:af:85:3a:c9:80:f9:cd
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
Validity
Not Before: May 13 00:00:00 2026 GMT
Not After : Sep 2 23:59:59 2032 GMT
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root X2
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
04:cd:9b:d5:9f:80:83:0a:ec:09:4a:f3:16:4a:3e:
5c:cf:77:ac:de:67:05:0d:1d:07:b6:dc:16:fb:5a:
8b:14:db:e2:71:60:c4:ba:45:95:11:89:8e:ea:06:
df:f7:2a:16:1c:a4:b9:c5:c5:32:e0:03:e0:1e:82:
18:38:8b:d7:45:d8:0a:6a:6e:e6:00:77:fb:02:51:
7d:22:d8:0a:6e:9a:5b:77:df:f0:fa:41:ec:39:dc:
75:ca:68:07:0c:1f:ea
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95
X509v3 Authority Key Identifier:
79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
Authority Information Access:
CA Issuers - URI:http://x1.i.lencr.org/
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://x1.c.lencr.org/
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
3d:bf:7b:d7:eb:98:cc:4d:a4:25:74:de:a5:07:7a:08:3e:31:
5d:b0:cf:de:b8:e1:8a:17:76:ab:47:f1:1c:96:61:c0:4e:ef:
17:e3:8c:61:17:75:4d:5e:fe:8d:0e:90:41:62:ca:75:02:39:
22:24:fe:f2:cb:a3:bb:6d:cf:a0:8f:01:e3:65:59:f0:b4:5c:
d9:28:19:e5:a0:2b:a8:e3:5e:fa:33:05:a1:ae:18:7e:67:d1:
47:e8:b2:13:1e:59:3b:94:46:a3:4d:e4:6d:34:b1:25:c3:4c:
1a:e9:a7:6f:a6:82:f7:59:42:36:fc:2b:5d:53:60:c0:36:e5:
00:3e:60:73:5f:6c:81:0b:d0:19:e2:02:12:92:da:0b:27:26:
34:b3:ad:d6:4b:23:e1:19:ed:21:32:a9:d4:76:ae:48:dd:d4:
ab:ad:2c:35:3e:9f:74:c5:cb:18:e7:89:95:46:ba:be:18:96:
13:0f:de:66:3f:75:5f:79:22:bb:80:92:48:ce:66:27:ab:ea:
11:81:74:48:19:5d:7b:da:0b:3f:6e:f6:25:44:69:db:08:13:
be:69:00:62:fc:a0:75:79:bf:17:40:44:38:a8:b5:1a:6e:97:
52:0d:fd:46:70:cc:06:eb:7d:41:5c:c3:51:e4:01:c6:03:fe:
69:59:7e:74:36:89:e0:85:d8:c4:bb:8f:75:61:bf:b2:4f:0c:
aa:78:e5:f9:b2:92:6c:d8:35:2a:ee:99:15:b4:ba:91:45:28:
30:4e:a0:5e:e1:b0:e6:fb:a0:bc:87:4b:e5:1f:b7:a8:ce:51:
f3:ab:a2:08:fc:61:4c:77:f2:12:9b:d8:ad:b4:af:8d:8e:82:
c4:9d:0d:dc:5d:79:85:9c:31:2d:d2:6f:a9:b0:25:e4:99:11:
8c:49:da:06:97:9c:34:8f:68:a8:61:ac:d9:18:c2:58:f2:55:
0c:ab:e0:da:be:30:42:72:b5:73:53:9c:7a:9a:01:ca:cd:c1:
99:55:a5:c2:4b:d4:a0:67:32:b3:23:3f:b7:9a:9e:f5:30:2f:
71:58:8f:77:05:d7:b8:ed:6e:82:ed:ee:02:e8:8b:8f:b6:ad:
66:45:be:7f:b0:e7:88:e6:77:f1:48:ba:18:59:70:46:94:ff:
0b:d4:e8:15:0d:32:d7:15:aa:e5:46:1e:9e:e2:b5:07:83:b6:
1e:63:f9:72:f7:8f:85:89:d9:20:01:c3:35:25:e8:e7:98:76:
0a:48:b7:f2:13:65:af:a9:4d:3d:26:43:fa:f9:5f:20:38:30:
40:22:69:b9:fb:5c:98:ef:08:44:65:17:67:5c:9f:6c:2a:27:
0f:82:ad:e4:e4:91:0d:91
Ah yeah, so they do exist, but I can't find those on either crt.sh or censys, interesting.
The cross-signature revocation and re-issuance likely took place in the same key ceremony, since they involve the same private keys.
This was just confirmed in 2038351 - Let's Encrypt: Gen Y Cross-Certified Subordinate CAs missing serverAuth EKU
Intermediates don't have to be submitted to CT logs, and I think in practice they usually aren't. Aggregators just get them when leaf certs (or precerts) are submitted using chains that include them.
And crt.sh I think is very behind in general right now anyway.
Yeah I just realized that you cannot even submit the intermediates to ordinary CT logs, because there's no log that will accept a certificate expiring in 2032... So the authoritative source for them is CCADB I guess.
(However, not even censys knows about them and they're very fast to update usually)
I'm not sure there really is an "authoritative source". That's why servers each have to be configured to send them. There's some timeframe before they have to be submitted to CCADB, and I think (though I may be wrong on this) that they could be in use (as long as servers include them as part of the chain) before that time. And while any cert intended for use in most browsers would need to have a precert submitted to CT (which would include the intermediate in the chain), I think (though again I may be wrong) that not doing so may keep the cert from being used in browsers but wouldn't be a root program or BR violation.
The new cross-signs are disclosed to CCADB, as well as in AIA.
While the intermediates aren't directly submitted to CT logs, I have submitted some certificates with the new intermediates in their chain so they are somewhat discoverable in CT:
curl https://mon.willow.ct.letsencrypt.org/2026h1/issuer/0fc0901cca2bae9e9fdbb02d50d02f1094f7b36672086991b9e897626dc485f0 | openssl x509 -noout -text -inform der
curl https://mon.willow.ct.letsencrypt.org/2026h1/issuer/072639d0b140d5bffae16ad9c3f6cc6086040621f51ee61a6d46a8915c07cf76 | openssl x509 -noout -text -inform der
curl https://mon.willow.ct.letsencrypt.org/2026h1/issuer/ee5f7abd6981bb0255632cd8f49283451b4b18844d12040b44ee00f07b8fe2c6 | openssl x509 -noout -text -inform der
I am currently working on an update to our website which will also have them there.
CAs are required to disclose via CCADB prior to issuing publicly-trusted certificates:
Disclosure MUST take place within 7 calendar days of issuance and before the subject CA represented in the certificate begins issuing publicly-trusted certificates.
(Common CA Database by the Linux Foundation)
(Mozilla Root Program Policy requires following CCADB policy)
So yes, you don't need to disclose them for 7 days, but only if you're not going to use them at all. So any cert not disclosed there is either irrelevant or not in compliance. The browser's use the CCADB as authoritative source (e.g. CRLite needs it to operate), so I would argue it is.
That would imply that the disclosure is late by several years for a certificate issued yesterday as X2 has been issuing publically-trusted certificates since before the cross sign.
No, since those were issued with an X2 certificate that was disclosed. This is a new certificate. Yes, it is using the same keypair (therefore making it interchangeable), but as far as certificates are concerned, this is a new certificate. Using it in a new issuance prior to disclosing would be a problem though.
While the self signed X2 certificate is used for issuing certificates, the phrasing of "the subject CA represented in the certificate" could just be referring to certain fields of the certificate including the subject and subject public key information which are the same between the self-signed X2 and new cross signed X2.
So the rule as written could potentially prohibit new certificates being issued for a subject CA which has already issued certificates.