Https://expired-isrgrootx2.letsencrypt.org/ is *not* expired

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

:stuck_out_tongue:

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 :stuck_out_tongue:

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: https://letsencrypt.org/certificates/".) 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.

1 Like

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