Hacker News Reader

Comment by SuchAnonMuchWow | Hacker News Reader

You are supposed to be able to revoke the certificate you misissue.

LetsEncrypt automated the certificate creation, which resulted in very large number of certificate issued. But at the same time, it should be possible to revoke them all.

If the revocation mechanism doesn't scale as much as the creation, this is a huge problem.

This time, the misissued certificates probably won't cause large issues. But they are misissued nevertheless and should be revoked.

If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?

View on HN

> If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?

As here, the severity of the issue should be weighed against the severity of revocation.

"Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".

By the way, following an earlier issue that did result in revocations, Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid. That means that early revocations may not cause outages for sites that are successfully using automated renewal with Certbot.

Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully.

I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.

Doesn’t that mean the cert is already invalid by the time certbot notices, so you already have an outage? And if certbot is running daily then that outage could be up to 24 hours.

Not if the last valid OCSP response is stapled to the certificate.

Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)

There was an idea we discussed of "intent to revoke", but it ended up looking like a quite a bit of work for a small benefit, so the situation is as mholt describes. :-)

For this specific reason, Certbot is recommended to run twice per day, and that is the default behavior in OS Certbot packages as well as the more recent official snap package.

Further to mholt's point, not all clients will enforce OCSP at all, while if you're using stapling, the client is being told about the last-valid OCSP response, so the outage would probably be a fairly small minority of clients in either case.

I know of at least one OS Certbot package where the check is only done weekly--FreeBSD. Would be interested to know if the twice-daily approach is the default in other OS packages.

Wow, thanks for pointing this out. Do you know who maintains this for FreeBSD, by any chance?

Technically, yes. However, if the certificate is used with With HAproxy or any other solution that provides a stapled OCSP response from some kind of cache (e.g. as a file updated by cron), it is possible to avoid the outage completely by fetching the fresh OCSP response every day, and not updating the on-disk copy if it says "bad". This way, the old but still valid copy is served to customers while the system takes the necessary steps to renew the certificate.

> Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid.

If anything mainstream actually checked OCSP, this seems like you'd still be effectively making the old cert unusable before the new cert was issued, which is unfortunate.

On the plus side, I don't think OSCP ever went mainstream.

OCSP is stapled automatically by Caddy, for example. It gets refreshed halfway through the response's validity period, so it will know well ahead of time if a certificate is revoked, allowing it to replace the certificate for you automatically. No downtime, no unusable certificate, etc, because even while it serves the revoked certificate, the OCSP response that is stapled to it shows valid for some remaining amount of time.

Of course, clients can do whatever they want to enforce OCSP, including pushing their own revocation lists and ignoring OCSP staples. Sigh.

Reply on news.ycombinator.com