[notrealyme123]

I think revoking them would be better in such a case.

[flakes]

One is not really better, you want both. Certificate revocation lists are loaded out of band and depending on the client can be poorly enforced.

Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it?

When the cert expires, it can be removed from the CRL, so shorter lived certs will allow CRLs to be smaller and faster to transfer.

[naturalmovement]

> Questions come up: do you block a request if you fail to download the latest CRL? How often do you refresh it?

In the before times we left settings like this up to competent system administrators to decide based on risk and not hardcoded by a handful of people at Google.

[dijit]

> competent system administrators

Sorry, we don't hire those anymore.

Best I can do is a YAML monkey who knows how to glue cloud services together..

[icedchai]

So true. The last time I worked with a person with an actual "system administrator" title was 2009!

[hdgvhicv]

Revoking doesn’t really work.

https://garantir.io/certificate-revocation-challenges-and-be...

[jzl]

Stale news. Mozilla introduced a new solution for certificate revocation that solves nearly all the problems with old methods. While it hasn't really taken off outside of Firefox, that's mostly because Google and Apple haven't embraced it because they are too busy trying to shorten certificate life unnecessarily.

https://hacks.mozilla.org/2025/08/crlite-fast-private-and-co...

[hdgvhicv]

> While it hasn't really taken off outside of Firefox

Thus doesn’t really work. Sadly.

[zx8080]

What is the reason that they are shortening it?

[naturalmovement]

Revocation doesn't work because a cabal of arrogant Googlenos and friends decided it's too hard to fix so we won't do it at all.

The last browser where revocation worked properly is Internet Fucking Explorer.