Hacker News Reader

Comment by c0balt | Hacker News Reader

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

Afaik, NGINX and Apache only have OCSP stapling support.

Note: for nginx there is https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_... which needs to be pointed to a pem-encoded file with the CRL list (list of revoked certs).

So no API-based configuration, like OCSP stapling, that just works. I can probably try to configure this with a cronjob/systemd timer but this is significantly less ergonomic.

You were previously using OCSP stapling for your server cert. The CRLs containing your server cert have nothing to do with your server. The server config you have found is for nginx to verify client certs.

Why would CRL require web server support?

So that admins find out that the certificate they have configured is no longer valid.

You’d need a monitoring solution for that, your web server won’t just send you a mail when it’s cert got revoked.

The client does that for you, by checking back at the CA. No need for any configuration server side.

For webservers, our recommendation is that your ACME client queries the ACME Renewal Information endpoint to find out if the certificate needs to be renewed:

https://letsencrypt.org/2023/03/23/improving-resliiency-and-...

Does ARI also return a suggested window of "right now" if the queried cert is manually revoked in the past? I was actually wondering this a few months ago when I implemented ARI in my ACME client - I also have a pending task to implement revocation checking, and if the ARI check makes that redundant it would be great. (Both the RFC and the LE blog only talk about querying ARI at some time before the CA decides to revoke the cert. My question is about querying ARI at some time after the user has revoked the cert.)

Yes, revoked certs will return "right now".

That's really nice. Thanks.

If your certificate has been revoked and you don't know that (e.g. from a very alarming e-mail), something has seriously gone wrong. In the general case, it'd be yourself requesting the revocation to begin with. But even if it isn't, I'm pretty sure the CA is supposed to tell you expeditiously.

Not all subscribers provide email addresses through which they could be informed of a revocation.

Ideally your server handles this automatically, which is why Let’s Encrypt is working on extending ACME to help with this case.

Some good implementations of ocsp stapling can already automatically get a new certificate if they receive a “revoked” ocsp response.

Requiring humans to read their email and be looped in is work I want to avoid needing at all.

To verify client and server certificates. For certificate-based auth this is quite important, but it's also nice to, e.g., know that your server cert is not revoked.

Your client does the checking of the server cert, no need for any configuration server side.

If you use certs for client auth it’s unlikely it’s used on the web and only in a company setting where you control the PCs, where you could just use something more suited for that case.

It's the client that is supposed to fetch the CRL. The server doesn't care unless it does client certificate authentication (which is incredibly rare due to poor UX.)

A server (nginx / httpd) might very well make outbound HTTPS calls and want to verify the origin's certificate to the fullest extent possible. This is known as a reverse proxy. However, many -- certainly not all -- reverse proxy configurations use origin servers that reside on the same exact network, and therefore don't need TLS connections (or use them with `SSLProxyVerify none` for e.g. self-signed certs to simplify things [0]), but I digress.

[0] https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslpr...

Reply on news.ycombinator.com