Intent to End OCSP Service

After I created OCSP Watch[1], I regularly detected CAs returning an OCSP response of unknown or unauthorized for certificates found in CT logs, indicating that they had basically forgotten that they had issued a certificate. I find that rather troubling. Indeed, OCSP Watch is currently reporting several forgotten NETLOCK certificates. (The certificates from other CAs are recently issued and will probably have OCSP responses provisioned in the near future.)

CRLs can't be used to detect this, because they only list revoked certificates rather than providing a definitive status for every issued certificate.

I do wish the root programs had merely removed the requirement to include an OCSP URL in certificates, but required OCSP URLs for every issuer to be disclosed in the CCADB. That would have solved the privacy problems and made OCSP responders much cheaper to operate, while continuing to provide transparency into the status of certificates.

[1] https://sslmate.com/labs/ocsp_watch/

Why not simply add the Must Staple restriction unconditionally to all certificates (aka "status_request")?

That will eliminate privacy concerns -- no compliant TLS implementation should fetch a OCSP ticket given a stapled response -- while still allowing for broad non-browser support.

letsencrypt is the nonprofit community-focused infrastruture that we imagined the internet would consist of 20 years ago. I love you letsencrypt.

"As soon as the Microsoft Root Program also makes OCSP optional, which we are optimistic will happen within the next six to twelve months, Let’s Encrypt intends to announce a specific and rapid timeline for shutting down our OCSP services. We hope to serve our last OCSP response between three and six months after that announcement. The best way to stay apprised of updates on these plans is to subscribe to our API Announcements category on Discourse."

Interesting to see Microsoft dragging here.

Certificate management is an interesting problem along the intersection of human behavior and computer science that feels similar to BGP. In theory, it's simple, but when met with reality things get messy really really fast.

For the major browsers, this probably makes little difference, but for anything else, this will most likely result in not verifying the revocation status of certificates anymore or making things slower.

As far as I know, most browser vendors already download the CRLs, and then update the browsers based on what they downloaded. For instance firefox seems to be using CRLite. There is a lack of support for something like that in the non-major browsers and non-browsers. The alternative they have is to download the CRL instead of the OCSP reply, which is larger, probably making things slower. Or they could just not check the status, which is most likely what will happen.

CRLite changes the failure mode of the status check, it no longer just ignores error in downloading the status information.

We need better support for something like CRLite.

Can someone ELI5 what does this mean for people using LetsEncrypt today with servers like Nginx or Caddy ? Do we need to make any changes to adjust ?

Interesting, how does the support for CRLs in web servers look?

Afaik, NGINX and Apache only have OCSP stapling support.

So if I'm not using Chrome or Firefox, how do I check for revoked certificates? This just makes the web less open again.

Are there any free or very inexpensive certificate providers which support ACME, DNS-01 challenges, and OCSP other than ZeroSSL?

CRLs don't scale, that's their problem and they take too long to update.

Why isn't there a standard binary format for CRLs that is a cuckoo filter or a similar data structure? That way you don't have to worry about a CRL ballooning to gigabytes and you can expect clients to fetch the latest binary blob frequently.

We collected some data [1] on the viability of only CRLs as the future (phasing out OCSP) - motivated by Let's Encrypt's announcement today [2].

Data is on CRL availability, number of entries, expiry & refresh times, etc. from various x509 leaf server SSL certificates.

[1] https://news.ycombinator.com/item?id=41058138 [2] https://news.ycombinator.com/item?id=41046956

Disappointing to hear considering the limitations of CRLs - is there any intention to go forward with OCSP stapling or is that completely abandoned at this point?

I'm curious how much of a factor this is. How often do certificates get revoked before expiration? I would think the only reason to revoke a certificate is if it was compromised.

Have we gone full circle?

Wasn't the point of OCSP to provide a low-latency and low-data alternative to CRLs, which might become massively huge?

Does anyone have a ready to go hosts blocklist for OCSP hostnames? Else, I could make one...

I… er… what?

First of all, privacy was one of the points of OCSP stapling.

Second, this breaks all non-http applications in the sense that they could previously work through OCSP stapling which would be communicated in-line. CRLs need to be fetched by the client, generally over HTTP.

Third, most non-browser TLS clients simply do not fetch CRLs, the implementation hurdle was too high.

… I'm left seriously befuddled by this decision by Let's Encrypt [edit: or rather the CA/B forum] :(

It would be nice if one didn't need to be a TLS expert to understand the post -- particularly since the whole point of Let's Encrypt was to democratize TLS access.

I have no idea if this means my setup will break even after consulting the docs of my ACME client.

Can I still use ACME Tiny[1] with nginx? Any reason to think that will break? How can I tell if I'm using OCSP or CRL?

Totally incomprehensible blog post.

[1] https://github.com/diafygi/acme-tiny