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 crt.sh 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] https://letsencrypt.org/docs/revoking/
[2] https://crt.sh/?id=1824297457

1 Like

Hi @hannob

that’s not a problem. It’s a Letsencrypt certificate, so you can download the leaf certificate - https://check-your-website.server-daten.de/?q=tlsseminar2019.space#ct-logs

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

2 Likes

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 cert-prob-reports@letsencrypt.org.

3 Likes

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

https://crt.sh/monitored-logs

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 https://github.com/letsencrypt/boulder/issues/4414

7 Likes

We implemented precertificate revocation for the RFC 8555 / ACME v2 API in Boulder master. It just missed this week’s release tag so it won’t be available in staging/prod until next week (following the typical release schedule). I’ll do my best to remember to update this thread when staging/prod are updated.

4 Likes

Quick update: we’re not going to be doing a release next week due to staff travel. Instead I expect the release with precertificate revocation will go out the week of October 1st.

2 Likes

:wave: Hi @hannob,

The staging and production ACME v2 APIs have both been updated to allow RFC 8555 revocation requests with a precertificate as the base64url-encoded DER certificate parameter.

Thanks again for the feature request/suggestion :+1:

3 Likes

I think it’s awesome that we have so much expertise, curiosity, and interaction within and among the members of our community and Let’s Encrypt staff. Ranging from idle conceptual questions about PKI to feature requests to bug fixes to correcting weird oversights in our and others’ infrastructure, the things that happen here are really great to witness!

5 Likes

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