Remove OCSP warnings

[georgmu]

What would you like to have changed?

Let's Encrypt will stop supporting OCSP ( https://letsencrypt.org/2024/12/05/ending-ocsp/ ), so there should be an option to disable the warnings or the warnings should be completely removed or downgraded to debug.

[mholt]

Well, there are already public certs that don't support OCSP. That is the point of the warning: we can't automatically replace a certificate that has been revoked if it doesn't have OCSP. So it is beneficial to warn the user when that is the case.

[georgmu]

CRL URLs?

Maybe only warn if there is neither a OCSP URL nor a CRL URL?

[mholt]

Caddy doesn't use CRLs though. (It's infeasible AFAIK.) So there's no benefit to warning, since it's not an expected feature or function of Caddy.

[georgmu]

Ok. But then in 3 months, there will be warnings when using Let's Encrypt all over since OCSP is no longer supported.

That's why I think it would be a good idea to allow to disable the unavoidable warnings.

[mholt]

I'll give this some thought. I don't want to induce "warning fatigue", but I also want users to know when they use a CA that does not support a critical privacy feature.

[AidanWelch]

Caddy doesn't use CRLs though. (It's infeasible AFAIK.) So there's no benefit to warning, since it's not an expected feature or function of Caddy.

But certmagic is not limited to Caddy. Unless it is developed primarily for use with Caddy?

[mholt]

That's true. Sometimes I lose track of which repo I'm in.

The point remains though: CertMagic is the library that is managing renewals and checking revocation.

[georgmu]

Maybe I am missing the point here or don't completely understand the topic:
Checking CRLs and certificate validity is a thing of the client (browser) and not of the server.

The thing about OCSP stapling is that it caches the validity from CA and sends it to the clients so that they don't have the ask the CA itself and leak information.

So OCSP without stapling should give a warning, but no OCSP at all, but CRL support, should be sufficient.

[mholt]

Well, to clarify, CertMagic uses revocation status as a clue to renew early. So, yes, OCSP and CRLs are normally concerns of the clients, but in TLS automation, they are of interest by the servers too. (Well, the good ones. 😇)

The problem is that there's not really a feasible way to implement revocation checking via CRLs, so that is probably of concern to the user: if their certificate is added to a CRL, CertMagic won't know it and replace the revoked certificate. Hence, the warning that that kind of protection will be missing.

[AidanWelch]

That's fair. Why is it not feasible? CRL size being burdensome to download and search through periodically?

[mholt]

Ah, found it -- there was a big discussion over the course of several years in this issue: caddyserver/caddy#2341

So, yes, that's basically right.

• Anyone can roll their own CRLs, effectively revoking certificates willy-nilly for any software that chooses to use those. There isn't a single CRL that CertMagic could use since revocation status effectively becomes anyone's opinion.
• CAs do operate their own CRLs, but yes, these can get large and cumbersome.
• Unfortunately, Go does not have a robust CRL parser... at least, not one that reads them in a streaming fashion. The whole thing needs to be read into memory.
• @Gr33nbl00d did write a streaming CRL parser (see the linked issue for details), but it hasn't seen production use AFAIK and CRL parsing is very nuanced/tricky. I think he's also been busy. That's a lot of pressure for a solo volunteer dev!
• Even if we could read large CRLs efficiently, which ones would we use? How often would we download the whole list? etc.

Implementation is just very tricky and there's lots of technical details to figure out.

[AidanWelch]

That's really unfortunate, and I can't think of a good solution other than what would basically being re-inventing OCSP. But thank you for answering!

[Gr33nbl00d]

Actually the code is used at least in production in our company (deployed at arround 10 installations) and also part of our ci/cd chain. But i doubt that our usage covers all possible use cases of CRL. For example delta lists and ldap are not supported by my implementation. And there are so many "switches" in the crl extensions...

As @mholt suspected, the problem is that I don't have enough time to fully support this project with the attention it needs.
But it try to do my best :) What would make sense is to split my plugin and the parser. Maybe some other go devs would be interested in crl parsing as well and could support this too. As this is not just a caddy topic.