Equivalent to PGP revocation certificates?

My domain is: cyfox.net

The version of my client is: certbot 1.21.0

I'd like to make sure I'm able to revoke my certificate if it's compromised somehow.

With PGP, I would do this by generating a revocation certificate from the private key and storing it on all my devices; with a PGP revocation certificate, you can revoke a public key without having access to the private key itself. This creates a much lesser risk if any of the devices it's stored on are compromised.

Is there a way to do something like this with a Let's Encrypt certificate?


Well, sorta kinda maybe. There are two ways to revoke a certificate using the ACME API:

  1. Use the certificate private key to sign the request
  2. Use the ACME account private key to sign the request

So, if you were worried about your certificate private key being compromised in such a way that you no longer have access to it, then you could securely backup your account private key somewhere different and safe (kind of like you would a PGP revocation certificate), and then use it to do the revocation if needed.

But, there are definitely some caveats:

  1. Unlike with PGP, if your certificate key is destroyed (that is, you no longer possess it but you're fairly certain that nobody else does either) then there's really no need to revoke because it's not like the public key is floating out there where someone else might try to send you a message using it. So, in that case, you could just make a new certificate and not really worry about the old one and just let it expire. I don't think you need quite the same precautions that you might with PGP, since the case of your private key being copied by somebody else but you no longer having it yourself seems pretty rare. But then again, it's something that could happen, so I suppose it's worth thinking about.
  2. The account key has more authority than just being able to revoke certificate keys. In particular, it can issue new certificates for any domain names that the account has validated within the previous 30 days, it can change the account contact email, and it can change the account key to a new key. The ACME specification actually says, "Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate." While I think that statement may be a bit overblown (and I know some people would argue that it's outright wrong), it is certainly true that the account key does more than just allow you to revoke certificates, so it's really not the equivalent to a PGP revocation certificate.
  3. On the other hand, I believe certbot specifically recommends to users to back up its configuration files (including the account key), somewhere else, so storing your account key elsewhere is probably a good idea, and if you do so and somebody literally steals your server with the certificate key on it such that you don't have it then the account key would let you do the revocation that ought to happen.
  4. But, weirdly, about a month and a half ago Let's Encrypt disabled the ability to submit a revocation request for a reason of key compromise using the account key and such a request is only allowed using the certificate key itself. So you could submit the revocation, but you wouldn't be able to explicitly flag it as a key compromise revocation. That means, for instance, that it wouldn't be automatically added to the list of no-longer-issue-certificates-for-this-public-key that Let's Encrypt maintains. This change has actually caused a lot of confusion in this community, and we're still awaiting an explanation of why exactly this change was made. Here's the thread on that.

I hope that mostly answers your question.


Let's Encrypt currently offers three ways of revoking certificates:

  • Via the certificate's private key (proof of key possession)
  • Via the same ACME account that issued the certificate
  • Via a different ACME account by proving it has control over the SANs in the certificate (basically using the same validation methods you would use for issuance)

Also see


Shoot, I forgot the third way and now I feel silly. Yeah, probably the easiest thing to do in a lot of cases where the certificate private key is compromised but you no longer have it would be to just validate control again with a new account and use that to revoke the old certificate. I still don't think you could mark that revocation as keyCompromise though since the change 6 weeks ago.


I see, thank you both! I had assumed that X.509 PKI would have something like this built in as PGP does, but that solution makes sense to me for a service like Let's Encrypt.


Yeah, how WebPKI works definitely has some differences to how the PGP Web of Trust infrastructure works. Actually, while falling asleep last night I realized that I had also forgotten a fourth method of requesting revocation, which while it kind of allows for this sort of thing is not something one should really build a "process" around. But I thought it might be instructive to explain it, just for completeness sake.

The official documentation of how Let's Encrypt works and what a Relying Party can actually Rely on is in two documents: A Certificate Policy (CP) and a Certification Practice Statement (CPS). [I'm not really sure why it's split amongst two documents, honestly, but it seems to be a part of how CAs work.] These documents are based on the Official Rules that all public Certificate Authorities need to follow as set out by the CA/Browser Forum. Specifically, for revocation, take a look at Let's Encrypt's CP § "Reasons for Revoking a Subscriber Certificate" and CPS §4.9.3 "Procedure for revocation request".

Based on those, you can see that anybody can provide "evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise" in order for Let's Encrypt to revoke that key, and that such a revocation request can "be made by emailing cert-prob-reports@letsencrypt.org".

So, here's what you do if you really need to have something like PGP revocation certificate: Whenever you create a new certificate (which again in the common case is every couple months due to the certificate lifetime, though you could reuse your certificate private keys which has its own set of security tradeoffs), use the certificate private key to sign a message along the lines of "The Let's Encrypt certificate with serial number nnnnnnn has a compromised private key." This could probably be automated with some kind of deploy hook, though of course securely transferring it to wherever you want to store this "revocation certificate" would take some care. There's not really anything built into the WebPKI to do such a cryptographic signature, but RSA and ECDSA allow for signing messages (that's how the fundamental TLS protocol works, after all.) I might recommend putting it in the format that pwnedkeys.com uses, perhaps using their pwnedkeys-prove-pwned program, which I'm guessing is as close to an industry standard that there is, but you may be able to hack something together yourself with an openssl command line like openssl dgst -sha256 -sign privkey.pem -out revokationmessage.sign <<< 'This key is compromised' and instructions on how to verify it.

Once you have a signed proof of compromise, that's your "revocation certificate". Keep it safe, give it to your buddy to use in case of emergency, and so on. If you need to use it, just email it to cert-prob-reports@letsencrypt.org and a human there will validate it and revoke the certificate within 24 hours.

And that last step, of course, is why I recommended at the beginning to not really build a process around this: It requires a human on the Let's Encrypt side, and so it isn't really scalable. Let's Encrypt is built all around automation, such that ideally everything goes through the ACME API protocol. But there is a stopgap available of getting a human involved for those rare cases that that's necessary. But I suppose if it were just you, for some weird reason you needed to do this sort of thing, and the 24-hour response time to actually get the revocation done was acceptable, it's a thing you could do.

Now, if this were a thing that multiple people needed to do, it might be worth trying to standardize some sort of attestation of compromise one could use, and an extension to the ACME protocol to allow for requests using it instead of needing to sign a request with the actual certificate or account key. But, well, I suspect it's the kind of thing that just isn't really needed.


Well, apparently I was mistaken, and this fourth approach wouldn't necessarily work, because emailing Let's Encrypt evidence of compromise, but not the private key itself, doesn't actually obligate them to revoke it, though of course they might so do anyway if they're able to (there's just apparently no Official Rule forcing them to do so like I thought there was). The only way to actually ensure that a revocation due to key compromise will happen is to use the ACME endpoint signed with the certificate private key itself.

Now, if you might be wanting to revoke for some other reason (like, you're selling the domain name soon or something), then you can use one of the other methods like storing the account key securely or having some other account prove ownership of the domain.


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