Revocation Issues with CRL for R3 (was: r3.o.lencr.org)

[JamesLE]

@petercooperjr

was this some sort of failure ... which would affect any system that checked the CRL signed by DST Root CA X3

Yes, exactly.

@petercooperjr

Is there not already monitoring around CRL (and OCSP) expirations?

We monitor the CRLs we generate, and our OCSP responder, but DST's operator monitors their own. It's likely that we'll explore extending our own monitoring (for the few months that the DST chain remains unexpired).

@petercooperjr

I'm guessing that the cause of error message some people were seeing around certificates not having OCSP were that R3-signed-by-DST only has a CRL listed, so when that failed the system was hoping to use OCSP instead but couldn't because there was no OCSP for that certificate?

Oddly enough, CRL expiration causes the same or similar error messages even when OCSP is also published and available (at least on some clients).

[petercooperjr]

Thanks again.

@JamesLE

for the few months that the DST chain remains unexpired

Hmm. So once the DST Root expires, the CRL won't get updated anymore? I wonder if that will cause this same kind of issue again for these clients that broke during this incident, unless the server they connect to switch to the "alternate" chain before then? I know there are some expected issues with old OpenSSL once the expiration happens, but I'm wondering if people might see something more widespread with these other clients that are checking CRLs? Or will they stop checking the CRLs when they see the root is expired as long as ISRG Root X1 is in their trust store?

I was trying to play around with this scenario in the staging environment (which has an expired DST-Root-X3-equivalent to help with testing this, right?), and The Staging-Pretend-Pear-X1-signed-by-Staging-Doctored-Durian-X3 cert lists a CRL of http://stg-dst3.c.lencr.org/ but that URL returns a 404 for me. Is that what will happen for http://crl.identrust.com/DSTROOTCAX3CRL.crl once the root expires, that it will turn into a 404? Or will there be some CRL there "forever" just with an expired signature? Or do we not know yet?

[jillian]

@petercooperjr

cert lists a CRL of http://stg-dst3.c.lencr.org/ but that URL returns a 404 for me.

This is currently intended. We set-up the new staging hierarchy to match Production but did not implement all of the details like CRLs. There was a balance for making this change in a timely fashion and providing enough similarity with Production for testing. Initially, we considered issuing a hierarchy where all the URIs were "fake" and not fetch-able but decided that was important aspect for testing. We don't have a timeline for configuring CRLs for Staging.

[petercooperjr]

For anybody interested in following IdenTrust's incident report on this (at least as reported to the Mozilla root program):

1709192 - IdenTrust: Unavailable CRL for IdenTrust ‘DST Root CA X3’.

[e1haskins]

SO I appreciate the information here, it explains why our certs show a broken chain of trust. I am assuming this is transient thing and that IdenTrust & the issues with OCSP stapling will ease themselves. Is there anything I need to do on my end to assure our users that the cert IS still ok? DO we have to reissue a new cert, or will the OCSP stapling errors we are encountering be resolved by the parties listed above?

[petercooperjr]

@e1haskins, the issue in this thread was just from 2021-04-30 19:41 - 2021-05-01 00:04 UTC (per Let's Encrypt's status page), and was about the CRL of IdenTrust (validating that Let's Encrypt's R3 intermediate wasn't revoked) not being updated. It's got nothing to do with OCSP stapling, so I'm a bit confused by your questions. There's no need to issue new certificates based on this incident.

But if you're having some sort of OCSP problem, I recommend starting your own new thread in the Help section and filling out the template the forum gives you there, including as much detail as you can about the problems you're seeing.

[e1haskins]

I will do that my issue was ALMOST identical to the one in the opening post of this thread except that mine started on the 3rd of May not April 30th. I literally just checked again and no more issue

[petercooperjr]

The first post of this thread has a screenshot from SSL Labs, and SSL Labs often can't connect to Let's Encrypt's OCSP server (which looks to be an issue on the SSL Labs side of things). It really has nothing to do with the problems in this thread, it just confuses people a lot since SSL Labs reports an error there even though everything's actually working fine.