Cannot revoke unlogged certificate despite being in posession of the private key

I think I stumbled upon an issue with certificate revocation and compromised keys.

Assume the following: I happen to find a compromised key somewhere (e.g. one accidentally published on pastebin or github) and I want to make sure the corresponding cert is revoked.

The docs [1] indicate that in this situation I can search for the cert. However not all certs are logged. While most certs end up in the CT logs sooner or later, sometimes only the precertificates are in the CT log. See e.g. this precert [2], the corresponding final cert is not in the log

However the revocation with certbot doesn’t work with the precert only.

So I could have a situation where I can’t revoke a cert with certbot, because I don’t have access to the real cert, but I know it exists, because I know the precert.

There have been previous discussions about not only logging precerts, but also logging final certs, but it seems right now mandatory logging of final certs is not happening.

I see several possible solutions:

  1. Make sure all final certs get logged.
  2. Allow certificate revocation based on precerts. This would probably involve a change of the ACME standard.
  3. Allow retrieving certificates from the API based on the private key or the serial (I thought I had seen something like this in the past, but I can’t find anything right now, maybe I’m just missing the right docs).


1 Like

Hi @hannob

that’s not a problem. It’s a Letsencrypt certificate, so you can download the leaf certificate -

Created a screenshot:

The tool lists the last certificate (leaf, if found, if not, precertificate). But if it is a Letsencrypt precertificate, it’s possible to use the serial number to download the leaf certificate via Letsencrypt.

A few days earlier I’ve added such a check. That’s the red marked link.

The idea - @mnordhoff

1 Like

That’s not going to work forever, though.

Once unauthenticated GETs are disabled, you will only be able to retrieve the certificate using the ACME account that originally issued it. (Or at least, that’s how it stands today).

It’s a little unfortunate that ACME doesn’t let you revoke by just the serial, but it’s probably too late to change that now. I don’t think having to present the exact certificate is required by any rules or even Let’s Encrypt’s own CPS.

Allowing revocation by precertificate seems to me like a reasonable way to fix this (possibly without changing the spec), especially considering that precertificates are the only reliable means to detect and react to a bad certificate, without resorting to emailing


FWIW, the final certificates should virtually(?) always be logged immediately (or, if there are errors, soon). The problem is’s backlog.

Precertificates get fired at several logs, so the Argon backlog isn’t a problem.

(I’m not certain if Let’s Encrypt logs to Oak yet, since it’s not usable anyway.)

Edit: Just found the Twitter subthread that discusses this.

Thanks for pointing this out, @hannob! I think the right approach is to accept precertificates to the revocation endpoint in the same way we currently accept certificates. We can do this in a non-API breaking way.

As @JuergenAuer and @_az pointed out, we do have a way to retrieve certificates by serial number in the current API, but this will be disabled when we start enforcing POST-as-GET (in 2020). I have found this endpoint useful, though. I’m thinking we should probably provide an equivalent endpoint that is not the same as the one provided as part of the ACME flow. That way we still help the ecosystem reach compatibility on POST-as-GET, but also provide the “fetch by serial” functionality separately.

Filed at