Establishing an Emergency Certificate Revocation Workflow

When hosting an online community, few incidents require faster intervention than server intrusion or exposed cryptographic keys. If attackers obtain access to your forum host, your private keys, or your DNS records, they can issue or abuse certificates to impersonate your forum. Having a documented emergency procedure ensures you invalidate compromised credentials quickly and restore trust. According to the guidance on Revoking Certificates - Let's Encrypt, revoking certificates corresponding to compromised private keys is an important practice and is required by the Let's Encrypt Subscriber Agreement. This walkthrough details an emergency revocation policy framework tailored for forum administrators.
Section 1: Incident Assessment and Reason Code Selection
Whenever you revoke a certificate through an ACME client, you must provide an authorized reason code. Revocation requests that specify any code other than those accepted by Let's Encrypt will be rejected. Your policy must map the nature of the incident to one of the valid reason codes:
- keyCompromise (RFC 5280 CRLReason #1): You must select this reason when you have reason to believe that the private key of your certificate has been compromised, such as when an unauthorized person has obtained access to it or the key was shared publicly.
- superseded (RFC 5280 CRLReason #4): Choose this reason when requesting a new certificate to replace an existing certificate on your forum server.
- cessationOfOperation (RFC 5280 CRLReason #5): Select this reason when your forum will no longer use the certificate because you are discontinuing the website or no longer control all domain names included in the certificate.
- unspecified or No reason provided (RFC 5280 CRLReason #0): When none of the other reason codes apply, you must not provide any reason code other than "unspecified".
Once you revoke a certificate, Let's Encrypt may publish revocation data in Certificate Revocation Lists (CRLs), which modern browsers consult to verify trust. For related infrastructure hardening steps after an intrusion, see our guide on Forum Admin Security.
Section 2: Revocation via the Original Issuing Account
The fastest revocation path applies when an attacker copied your private key off your server, but you have maintained intact access to your host and the original ACME account credentials. By default, Certbot attempts to authenticate the revocation request using the local subscriber account credentials stored on disk.
To revoke a compromised certificate directly through your original account, run the Certbot revocation command pointing to your archive certificate file:
certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem
If you suspect an active intrusion, ensure you preserve forensic evidence before wiping the server or replacing credentials.
Section 3: Revoking Unauthorized Certificates Issued by Attackers
If intruders gained temporary control over your forum host or your DNS configuration, they may have validated and issued a certificate for which they hold the private key. Once you regain control of your infrastructure, you will want to revoke that fraudulent certificate immediately. Because you do not hold the attacker's account credentials, you must prove to the Certificate Authority that you control the domain names listed on the certificate.
You can prove domain control using standard validation methods, such as placing a value in a DNS TXT record or placing a file on an HTTP server. Because most ACME clients combine validation with issuance, you can validate your identifiers while preventing unnecessary certificate issuance by adding a deliberate non-existent domain to your request. For example:
certbot certonly --manual --preferred-challenges=dns -d ${YOUR_DOMAIN} -d nonexistent.${YOUR_DOMAIN}
Follow the prompts to complete the challenge for your real domain, and skip the validation step for nonexistent.${YOUR_DOMAIN}. This intentional failure prevents issuance while proving control over your actual domain. If you prefer validating over HTTP rather than DNS, replace --preferred-challenges=dns with --preferred-challenges=http. Note that the DNS approach will not work if you swap the manual flag for an automated DNS-01 plugin, because automated plugins will place a challenge TXT record at _acme-challenge.nonexistent.${YOUR_DOMAIN} automatically.
After proving control over the domains, locate the unauthorized certificate in Certificate Transparency logs via an online monitor like crt.sh, download the file, and execute:
certbot revoke --cert-path /PATH/TO/downloaded-cert.pem
Under these conditions, if the request comes from an account that did not originally order the certificate, Let's Encrypt may ignore the requested reason code and record the revocation as cessationOfOperation.
Section 4: Direct Revocation Using the Private Key
In instances where an administrator accidentally shares a forum's private key publicly, anyone holding that key can execute a revocation request without needing access to the original ACME subscriber account. This ensures rapid mitigation of public key exposures.
To use this procedure, verify you have a copy of the private key in PEM format. Next, download the corresponding certificate from a public Certificate Transparency log monitor such as crt.sh. You can match the exact certificate by searching for the SubjectPublicKeyInfo (SPKI) field. Extract the SPKI hash from your private key using OpenSSL:
openssl pkey -outform DER -in /PATH/TO/privkey.pem -pubout | openssl sha256
Once you match and download the certificate, sign the revocation request directly with the exposed private key:
certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/privkey.pem --reason keyCompromise
As outlined in the official documentation on Revoking Certificates - Let's Encrypt, if the request is signed using the certificate private key instead of an account key, the Certificate Authority may ignore any alternate reason code and automatically mark the revocation as keyCompromise. For recurring maintenance, review our guide on Free HTTPS for Your Forum With Let's Encrypt.
Sources
Published October 30, 2026. No affiliate links on this page. Facts come from the sources linked above; check them for updates.