Best Practices for Certificate Revocation¶
When to Revoke¶
Revoke Immediately on Key Compromise¶
If you have any reason to believe a private key has been exposed — through a server breach, accidental logging, insecure transfer, or storage in a location that was accessed by unauthorised parties — revoke the certificate immediately. Use the reason keyCompromise.
Do not wait to confirm the compromise with certainty. The cost of an unnecessary revocation (re-issuing and redeploying a certificate) is far lower than the cost of continuing to trust a potentially compromised key.
Revoke When Decommissioning Services¶
When a service is decommissioned, revoke any certificates issued for its domain. A certificate for a domain that no longer resolves to an active service is unnecessary and represents an opportunity for misuse if the private key is later recovered from decommissioned hardware.
Use the reason cessationOfOperation.
Revoke Superseded Certificates Promptly¶
When you re-issue a certificate — for example, to change the algorithm, adjust the SANs, or rotate before expiry — revoke the old certificate once the replacement is deployed. Use the reason superseded.
Having multiple active certificates for the same domain is not inherently dangerous, but it increases your attack surface and makes auditing harder.
Do Not Revoke Expired Certificates Unnecessarily¶
Expired certificates are already untrusted by relying parties. Revoking an already-expired certificate has no practical security effect and adds noise to your revocation records. Focus revocation effort on certificates that are still within their validity period.
Incident Response¶
Act Within Your Incident Response Window¶
For publicly trusted certificates, many browsers and clients have a maximum tolerance for CRL/OCSP staleness — typically 7 days. Revocation needs to be submitted to the CA before this window closes for the revocation to be reliably propagated.
For Local PKI certificates, the window depends on how frequently your relying parties retrieve the CRL. If you are distributing a CRL, shorter CRL TTLs mean revocations propagate faster but increase CRL fetch load.
Replace Before You Revoke in Production¶
For production services, deploy the replacement certificate first, then revoke the old one. This order avoids a window where the service has no valid certificate. Coordinating replacement and revocation ensures continuity.
For key compromise incidents, the priority shifts — revoke immediately even if a replacement is not yet ready, and accept a brief outage if necessary. An active compromised certificate is a more serious risk than a temporary service outage.
Document the Reason¶
Always provide a revocation reason. The reason is stored on the certificate record and included in audit logs. During an incident post-mortem or compliance review, having a clear reason code is significantly more useful than an empty field.
Post-Revocation Hygiene¶
Confirm Removal from Hosts¶
After revoking a certificate, run a Discovery Job against the hosts where the certificate was deployed. A recently revoked certificate that still appears in discovery results means it has not been removed from the server.
A certificate that is revoked but still being served will trigger trust failures in clients once CRL/OCSP propagation reaches them. Catching this before clients do is important for service continuity.
Do Not Reuse Private Keys¶
After revoking a certificate due to key compromise, generate a new key pair for the replacement. Reusing the private key from a revoked certificate defeats the purpose of the revocation.
For certificates issued via the automated pathway (where the BCP generates the key), the replacement request will automatically generate a new key pair.
Audit Revocations Periodically¶
Review the Revoked Certificates report periodically to:
- Confirm revocations were followed by replacement deployments.
- Identify patterns of frequent revocation in a particular domain or team, which may indicate a process problem.
- Verify that certificates revoked for
keyCompromisewere replaced promptly.
ACME Certificates¶
Revocation is not yet implemented for ACME-issued certificates in the platform. If you use ACME-issued certificates, ensure you have a separate process for revoking them directly through your ACME client when needed. Track ACME revocations manually and note them in the audit log if your compliance process requires it.
Summary¶
| Scenario | Action | Reason code |
|---|---|---|
| Private key exposed | Revoke immediately | keyCompromise |
| Service decommissioned | Revoke when decommissioning | cessationOfOperation |
| Certificate replaced | Revoke after replacement deployed | superseded |
| Staff member departed | Revoke personal-use certificates | affiliationChanged |
| CA compromised | Revoke affected certificates | cACompromise |
| Certificate expired | No action required | — |