One of the tenets of Let’s Encrypt is automation, this event exposes a very big spot where automation would make complete sense and could spare a lot of problems: there should probably be a mechanism to (safely) retrieve a “ProbablyAboutToBeRevoked” warning for a certificate, along with such probabl…

I remember a discussion about this idea in the early days of the ACME protocol, but it never made it in. One of our colleagues argued that it would be useful because in some cases there could legitimately be a delay between the CA’s knowledge that a certificate must be revoked and the actual revocat…

Related: https://github.com/certbot/certbot/issues/1028#issuecomment-593985897 and: fetching OCSP for stapling may help: https://twitter.com/caddyserver/status/1234874273724084226 that way, when an OCSP response fetched says "revoked" there is still time to renew the cerficate until the previous O…

Would it be onerous for Boulder to provide an API endpoint that checks for a certificates’ “revocation pending” status? Perhaps by the serial number or something else that is small in size and does not require the overhead of authentication. Clients like Certbot would check that endpoint every 3 da…

We’ve had numerous internal discussions about some sort of generalized ‘renewal hinting’ API that clients could use to learn not just about immediate renewal needs (i.e. because of revocation), but also about generally when the CA thinks the client should renew. We’re planning on writing up some of…

It would be awesome if this could also get standardized (like the ACME protocol). Who knows, maybe even as an ACME extension?

What would be the advantage compared to using the OCSP and relying on the duration of the validity of the answer? If the website uses OCSP stapling, with Certbot 1.3.0 who check the OCSP answer, I think any downtime can be avoided: When the certificate is expired, until the new OCSP - revoke - an…

@tdelmas , that suggestion is very interesting; but do you know if there are any TLS clients that will ignore OCSP stapling and still make their own independent OCSP query?

[image] schoen: if there are any TLS clients that will ignore OCSP stapling I'm not aware of any, more testing could be done using a recently expired certificate with browsers that do check OCSP.

[image] tdelmas: If the website uses OCSP stapling, with Certbot 1.3.0 who check the OCSP answer, I think any downtime can be avoided: Couldn't certbot just make the OCSP request itself to the CA, without concern for ocsp stapling by the website?

Ability for Automated Notification of Revocations

Feature Requests

Gabf March 6, 2020, 12:46pm 8

Unfortunately I'm not allowed to edit the post, but it should be clarified that "this event" was referring to revoking-certain-certificates-on-march-4.

Topic		Replies	Views
Self-trigger 5 day (120 h) or 24 h revocation (for ARI validation) Feature Requests	16	355	January 7, 2025
OCSP or ARI + OCSP to check revocation status Issuance Tech	19	861	June 13, 2024
What will happen to Must-Staple Issuance Policy	32	3597	July 27, 2024
Sometimes it's required to break the rules - and to change these Praise	18	4029	March 7, 2020
[Poll] Do we need longer cert validity times? Issuance Policy	49	10047	April 10, 2016

Ability for Automated Notification of Revocations

Related topics