https://expired-isrgrootx2.letsencrypt.org/ has a valid cert despite it's name.
1 Like
Please read the note on the page you're linking to, thanks.
3 Likes
facepalm, sorry about the noise!
4 Likes
I think I've asked someone from Let's Encrypt this myself by the way. The reason is Let's Encrypt has used their regular infrastructure to issue the certificate for that site and that means it followed the regular issuance "rules". I.e.: they couldn't issue a certificate with a validity in the past. The infrastructure just issued a regular cert and they (Let's Encrypt) have to wait until it has expired.
3 Likes
While it might be nice for Let's Encrypt to design, implement, and test a system whereby people can request certificates with shorter-than-90-day durations (I'd probably have used some 30-day-or-so certs myself once or twice if they were available), I can certainly understand why adding such a feature isn't at the top of their to-do list.
2 Likes
I'm not reading any feature request here @petercooperjr ?
2 Likes
No, I probably worded my comment weirdly.
I'm trying to say that, because Let's Encrypt has the quite-helpful-in-preventing-incidents philosophy of only ever using the public interface for creating certificates, in order to create an "expired" certificate (or one that would expire sooner than normal), they'd need to create a way for anybody to request such shorter-duration certificates.
4 Likes
Indeed, that's the reason why they issued a "regular" cert for this specific website: there's just not a way to do it differently
4 Likes
Though now I'm curious if that test site not actually being expired yet might be a BR violation. BR 2.2 says that
The CA SHALL host test Web pages that allow Application Software Suppliers to test
their software with Subscriber Certificates that chain up to each publicly trusted Root
Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are
i. valid,
ii. revoked, and
iii. expired.
So it's not clear to me whether ISRG Root X2 counts as a "publicly trusted Root Certificate" yet that is covered by that requirement. While it may not be in the various root programs yet (as that takes quite a while), it is labeled as one of the "Root Certificates" in the official Let's Encrypt repository (Like, the CPS section 2.2 says that "Records of all ISRG root and intermediate certificates, including those that have been revoked, are available in the Certificate Repository: Chain of Trust - Let's Encrypt".) But I guess it might not be "publicly trusted" yet, perhaps? I could have some system where I specifically added ISRG Root X2 to my trust store based solely on Let's Encrypt's publishing of the certificate and the embedded OID promising that it fulfills the Baseline Requirements, even though it actually won't be fulfilling all the requirements until the test site certificate expires? But that's just me "privately" trusting it maybe, and the requirement doesn't matter until it gets "public" trust?
I'm probably overthinking this, like I usually do.
2 Likes
I'm currently not aware of the status of the X2 root inclusion in the public programs. I think you privately trusting a certificate wouldn't violate any BR article.
Just 4 more days until the cert expires, so unless one of the root programs includes X2 within this little time, I guess LE is safe.
2 Likes
It has expired and the note will be removed soon!
Correct, there are no manual ways to issue a certificate from Let's Encrypt and we feel it's safest to use our ACME endpoints with their normal configuration to issue this certificates and wait for it to expire. The CA software, Boulder, can be configured to issue certificates of any length but we didn't want to accept any of the risks of making that change for a single certificate issuance.
4 Likes
Well, for me it doesn't matter 
You cannot visit expired-isrgrootx2.letsencrypt.org right now because the website uses HSTS.
Can't seem to overrule it! I'd have to remove the HSTS data from Chromium to see the page again
1 Like
Not being able to overrule ("click through") this is actually one of the features of HSTS.
See rfc6797 section 12.1: No User Recourse
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.