Ability for Automated Notification of Revocations

You may have read that in one of the articles that is referenced in Matt Hobbs's blog post, but according to that it only pertains to EV certificates.

how much load to DB if we start a extension that checks for “will be revoked”? this isn’t something that can be cached, isn’t it? as it only make sence to check when there is mass revocation event (as user requested revocation will active , a cacheable page say that there is no cert that marked for revocation may make sense to reduce server load?

2 Likes

@orangepizza That may be good, but the downside of services that only receive high load during an emergency is that you can’t predict what their load will be and make sure that they can routinely handle it…

2 Likes

It the goal is automation, the ACME client will always check it because it can’t know if a mass-revocation will occur, so, the load will always be the same, and predictable, no?

1 Like

I was thinking about having a status page :“is there any mass revocation waiting?” so client doesn’t need to check individual cert’s status until the event of mass revocation

1 Like

The “individual” entry point could returns the static response “no” when the “mass revocation mode” is not activated.

1 Like

I think that “Please renew” and “There is a problem” notifications within ACME would be super valuable.

One reason is as others have mentioned that you can automate renewal based on them, unlike email notifications. This is useful not only in potential future mass-revocations, but maybe also for individual revocations like private key compromise, or external events such as a TLD compromise.

Another reason is that for private projects and some organizations, email may be a very effective communication medium, but for other organizations, the contact email could easily end up at an email alias that is not closely monitored, or an employee that no longer works at the company. If the notification is sent to the ACME client, the client can log it and feed it into the normal monitoring and alerting applications used by the organization. In the systems I work with, this would be more likely to be noticed than an email notification.

I don’t think checking the OCSP response and caching the last good response is an ideal solution. Not only because of the uncertainty if some relying parties will check OCSP but not support stapeling, but also because the CA would have no way of knowing if the ACME client supports this way of renewing. The CA would therefore blindly revoke the certificate without knowing if it will trigger an automated renewal by the ACME client. Sending the please renew notification in an authenticated ACME message would allow the CA to send the notification and then monitor the reaction before deciding when to finally revoke the certificate.

A challenge with these notifications is to design them in a testable way. It should be possible for the subscriber to trigger the notification for his own certificates to test the ACME client’s response.

2 Likes

Joining too late, I know, but a few comments worth considering:

  • If a certificate is going to be revoked, there is already a trust issue, i.e. the certificate is as good as revoked. (if you only read the first part of my post, at least read this point!)

  • Some clients do/can ignore OCSP staples, even Valid ones, if their vendor distributes their own revocation lists (like Apple, AFAIK).

In other words, an endpoint to check a certificate’s status is… exactly what OCSP is, and won’t solve the problem.

If it is known that a certificate is going to be revoked, and if we want clients to be able to act on that information, it must effectively be kept secret and shared only with the active client. There are some more problems however:

  • Most clients are not always on. Many are just on a timer. More ACME clients would need to be like Caddy or CertMagic, which can actively receive incoming signals any time and act on them.

  • The idea of secretly communicating distrust seems counter to the idea of CT, which is intended to increase transparency. If one client can know that a certificate isn’t trustworthy, why can’t relying parties know too? (I know there are “Yes, but…” answers to this, but they’d all require reframing the BRs and convincing clients that these changes acceptably align with their threat models.)

I believe we’re tredging into territory that is much more complex than “simply” lowering certificate lifetimes.

1 Like

I don’t like the notion of delaying revocation at all. Revoke everyone’s certificates immediately, notify them as quickly as possible, services will go down (as far as revocation is effective), and the world will burn for a while until ACME clients or subscribers automatically or manually replace the certificates.

On the other hand, there seems to be a good argument that automated certificate replacement is enough of a game changer that it it’s the lesser evil – in some cases – to delay revocation for up to, say, 12 hours when the infrastructure is in place to reissue certificates within that timeframe.

CAs have always had the ability to play deadline chicken, whether or not they admitted it, but it’s difficult without automation, and was more difficult before the 5 day deadline for some revocations, and I don’t know if anyone had officially systemized it before.

1 Like

That's only if:

  • TLS servers (ACME clients) aren't stapling Valid OCSP responses (they should be)
  • Vendors are distributing their own revocation lists faster than OCSP staples AND prioritizing them over OCSP staples (Safari might do this, but meh)
  • ACME clients in general continue to be half-baked or partial solutions to the whole problem of TLS automation

In theory, a client that receives a signed OCSP staple that is Valid should simply be able to trust the certificate. I suppose it's up to vendors if they want to override that with their own lists, but, they risk causing mass warnings in times of mass revocations.

Yet, ACME clients that are properly stapling and monitoring OCSP responses should have no problem replacing certificates before the response expires.

This is the sweet spot, where revocations do not need to be predicted/delayed (which is the same as already not trusting the cert immediately -- see my post above) -- and clients have ample time (a few days, at least) to replace certificates. Caddy proves that this can work (if clients are responsible and not overly-aggressive).

(Of course, even better would be to simply lower certificate lifetimes to the point where revocation is needless.)

Very interesting topic. I’ve just pushed a commit to uacme on github, which makes it check the OCSP status of the certificate; if the responder reports it revoked, reissuance is forced regardless of the expiration date.

I run uacme in a cron script (daily but can easily be more frequent without any issues). Therefore if the certificate gets revoked, it will be automatically renewed next time the cron script runs. It’s not instantaneous but very simple and importantly automatic.

2 Likes

That’s great! AFAIK yours is only the second client to implement that. We’re hoping more clients will implement the counsel on https.dev. :slight_smile:

2 Likes

Is the first one Certbot? (Certbot now has this feature too.)

2 Likes

I know of 2 different cPanel-based Let’s Encrypt integrations that check OCSP as well (one since 2016-7).

There’s probably quite a few “stealth mode” clients that do it, now that I think about it.

Would be great to see it in acme.sh and dehydrated, that’d probably cover quite a huge number of users. Plus openssl ocsp existing should make it a bit easier.

1 Like

Ah, I saw that in the release notes a couple weeks ago, I think that’s great!

But no, I was referring to Caddy/CertMagic, has has been doing it since before the mass revocation incident…

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.