During a problem with my DNS registrar, an individual was able to issue a Let’s Encrypt certificate for my domain. The DNS was restored afterwards, but the certificate remains valid.
As you can imagine, I do not have the information used for requesting the certificate (email, account key or domain key).
I tried to issue other certificates to replace that one, in which I have succeeded, but the original certificate was not revoked.
I also tried to use my new account key to revoke the certificate created by the attacker, but I was not able to do it.
Therefore I have two questions:
How can I proceed to revoke this rogue certificate? I now have restored full control of the domain and can provide authentication by any means necessary.
Once revoked, would it be possible for the attacker to renew that certificate (or issue a new one) since he/she still has the old account and domain keys?
In this case, however, it’s most likely that no action will be taken on our end because we will not be able to validate your claim. It’s not that we don’t want to help, the problem is that an investigation to determine the validity of your claim would be quite difficult. As far as we know, the certificate was properly issued to an entity controlling the domain, and if we were to revoke it based on a written request like this we could be denying service to a legitimate subscriber. I suspect you’re an honest person but that isn’t true of everyone, unfortunately. Denial of service attacks are a real problem.
The good news is that that certificate and the associated authorization will both be gone in < 90 days. This situation is one of the reasons we’re enthusiastic about short-validity certificates.
I understand it is difficult to the determine if a request like this is valid or not. But I would suggest you allow for revoking of previous certificates when a new certificate is requested and the domain verification is completed.
Regarding the certificate expiration in 90 days, I’ve got another question: if the attacker tries to renew the certificate before 90 days have passed, would he be able to do it without validating the domain again? This would give him another valid certificate for further 90 days without having access to the domain. Is that right?
Yes. The validation -- authorization -- lasts for a certain amount of time. I think it's currently 90 days, though they intend to lower it further: Upcoming API changes The attacker can continue issuing certificates until it expires, covering a total of about 179 or 180 days.
@pogsoft, there is no ability to renew certificates indefinitely just based on possession of the certificate. However, there is a resource called authz in the client that refers to a successfully completed domain-control validation. An individual authz can be reused to renew/reissue a certificate without reperforming the challenge, until that authz expires. After that, the validation challenge must be reperformed in order to get a new authz to issue future certificates.
The authz lifetime was cut down to 90 days some time ago and I believe it might have been reduced further since then.
So, the other person (if they're aware of the existence of the authz and saved the associated information in their client) could issue new certificates at any time during the authz lifetime period following when the challenge was most recently successfully performed.
You're probably aware that all Let's Encrypt certificates are published publicly and that you can search them at
so you can watch to see if this happens.
[Edit: this suggestion doesn't work; see discussion below!] If you control the DNS for the domain, you can also use the Certificate Authority Authorization (CAA) protocol to prevent any new certificate issuance by Let's Encrypt (regardless of whether someone is in possession of an authz, I believe). If you want, you could set CAA records for your domain that forbid Let's Encrypt from issuing any certs. If you want to renew your own certificate, you could temporarily remove the CAA records at that time, allowing your renewal to go through, and then restore the CAA records, blocking anyone else from performing a renewal. You could maintain these records in place for at least 90 days to ensure that an authz held by someone else cannot be used for new issuance.
Edit: recently the authz validity time was lowered to 60 days, which might apply to the authz in this case.
In addition, an individual who is not the Subscriber may request revocation of a DV-SSL Certificate if the individual can demonstrate ownership or control over the device, and ownership or control over the domain.
Section 4.9.3 says:
If a Subscriber does not have access to the Private Key associated with the Certificate to be revoked or the relevant AMCE account key, the Subscriber may re-authenticate (successfully respond to challenges) for the domain and then request revocation using the new ACME account key associated with the domain to be revoked.
DV-SSL Certificates can also be revoked after a conclusive investigation of a Certificate, conducted in accordance with section 4.9.13, that is initiated by a report received via email.
In this case, i'm not sure @pogsoft counts as the Subscriber -- the attacker is -- but they should be able to revoke it. Possibly technically fraudulently.
You know revocation doesn't entirely work, right? An active MITM likely has the ability to block CRL and OCSP checks, when clients even bother to make them.
CAA is checked at validation time, so I think once you have a valid authorization for a domain, you'll be able to continue requesting new certificates until this authorization expires. This recently came up on cabfpub in connection with a Google domain.
@pfg, I also confirmed this with other developers. In Let’s Encrypt’s implementation, CAA can’t be used to prevent issuance post-validation, so it’s not useful for @pogsoft’s situation. Sorry about that, and thanks for the correction.
If the truth of the situation is that an error was made by the DNS registrar, might documentary evidence as to this from the registrar be enough evidence for an investigation to conclude the certificate should not have been issued, even though Let's Encrypt did nothing wrong? For example if the DNS registrar's people were to arrange to take a call from Let's Encrypt and talk through exactly what went wrong and when, this could be compared to your logs.