Certificate revocation is one of the most important yet overlooked parts of Public Key Infrastructure. When a certificate can no longer be trusted before its expiration date, the issuing Certification Authority (CA) revokes it and publishes that status through mechanisms such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP).
Revocation status tells relying parties that a certificate should no longer be trusted. A revocation reason code adds context by explaining why, and that information is carried in the CRLReason extension defined in RFC 5280.
Understanding CRL reason codes helps PKI administrators, security teams, auditors, and compliance teams tell the difference between a routine certificate lifecycle event and a genuine security incident. This blog covers what the codes are, the values RFC 5280 defines, how they differ from ReasonFlags, how public TLS policy constrains them, and the practices that keep revocation data useful.
What are CRL Reason Codes
A CRL reason code is a standardized value that can be included in an individual CRL entry to indicate why a certificate was revoked. RFC 5280 defines CRLReason as an optional CRL entry extension associated with a revoked certificate, so rather than only marking a certificate invalid, the CA can record the reason behind it.
That distinction is operationally significant. A certificate revoked because it was replaced by a newer one calls for a very different response than a certificate revoked because its private key was compromised. Because the codes follow a common standard, certificate lifecycle management platforms, monitoring systems, and security workflows can process revocation events consistently across different PKI environments.
CRL Reason Codes Defined in RFC 5280
RFC 5280 defines the CRLReason values as an ASN.1 enumeration. The numeric code matters, because it is what actually appears in the certificate’s CRL entry.
| Code | Reason | Meaning |
|---|---|---|
| 0 | unspecified | No specific reason is given |
| 1 | keyCompromise | The certificate’s private key is known or suspected to be compromised |
| 2 | cACompromise | It is known or suspected that the issuing CA’s private key has been compromised |
| 3 | affiliationChanged | The subject’s name or affiliation information has changed |
| 4 | superseded | The certificate has been replaced by a newer certificate |
| 5 | cessationOfOperation | The certificate is no longer needed for its original purpose |
| 6 | certificateHold | Temporary suspension of the certificate |
| 8 | removeFromCRL | A certificate previously on hold is no longer revoked; used only in delta CRLs |
| 9 | privilegeWithdrawn | A privilege contained in the certificate has been withdrawn |
| 10 | aACompromise | An Attribute Authority key is known or suspected to be compromised |
Value 7 is intentionally reserved and is not used, which is why the enumeration skips from 6 to 8. Mapping these codes off by one, by forgetting that 7 is absent, is a known source of real-world CRL defects, so the gap is worth keeping in mind. Not every CA uses every code, and public TLS ecosystems restrict which reasons are permitted, as covered below.
Why Revocation Reasons Matter
Revocation status tells you whether a certificate can still be trusted. Revocation reasons tell you why it can no longer be trusted. The difference resembles the one between swapping an expiring credit card for a fresh one and reporting a card stolen: both retire the old card, but only the second signals fraud and calls for an urgent response.
If a certificate is revoked with keyCompromise, security teams usually need to investigate possible credential exposure, rotate affected keys, and assess whether systems were breached. A certificate revoked as superseded, by contrast, often reflects normal lifecycle management, such as replacing an expiring certificate with a renewed one. This context improves incident response, compliance reporting, audit investigations, lifecycle automation, and root-cause analysis.
Organizations with large certificate inventories rely on it to prioritize remediation and cut operational noise. In practice, accurate revocation metadata is what makes a certificate lifecycle program measurable and auditable.
CRLReason and ReasonFlags are Not the Same
One of the most common PKI misconceptions is treating CRLReason and ReasonFlags as the same thing. They are not.
CRLReason is the revocation reason tied to a specific revoked certificate entry in a CRL, and it explains why that individual certificate was revoked. ReasonFlags is a BIT STRING used inside the CRL Distribution Points extension to indicate which categories of revocation reasons a particular distribution point covers.
| Component | Purpose |
|---|---|
| CRLReason | Explains why a specific certificate was revoked |
| ReasonFlags | Indicates which revocation reasons a CRL distribution point covers |
In practice, CRLReason describes the revocation event itself, while ReasonFlags helps certificate-consuming applications and systems determine where the relevant revocation information can be found. The distinction matters when you are troubleshooting validation issues, designing a PKI, or reviewing a certificate profile. The broader role of trusted issuers in this chain is covered in Encryption Consulting’s overview of the certificate authority.
How CRL Reason Codes Affect TLS Operations
Although RFC 5280 defines the full set of codes, real-world TLS ecosystems add policy on top. Publicly trusted CAs operate under the Baseline Requirements and browser root program policies, and those rules narrow which reasons are allowed for publicly trusted certificates.
Two restrictions are worth knowing. The Baseline Requirements (BR §4.9.1.1) state that for a TLS certificate, the CRLReason must not be unspecified (0); if no specific reason applies, the CA omits the reasonCode extension entirely. They also prohibit certificateHold (6) for TLS certificates, and several codes such as cACompromise, removeFromCRL, and aACompromise do not apply to end-entity TLS certificates at all. In day-to-day use that leaves five permitted reason codes:
- keyCompromise signals a security event and usually triggers urgent action.
- superseded indicates a routine certificate replacement.
- cessationOfOperation appears when a service or application is retired.
- affiliationChanged applies when organizational ownership or authorization changes.
- privilegeWithdrawn is used by the CA when there is evidence of certificate misuse or a material violation of the subscriber agreement.
Modern revocation combines CRLs, OCSP, Certificate Transparency monitoring, and increasingly short certificate lifetimes. In April 2025 the CA/Browser Forum adopted Ballot SC-081v3, which phases the maximum validity of publicly trusted TLS certificates down from 398 days to 47 days by 15 March 2029. The first cap of 200 days took effect on 15 March 2026, with a further reduction to 100 days on 15 March 2027, and a final cap of 47 days on 15 March 2029.
Over the same period, the domain-validation data-reuse window shrinks to 10 days. Together, these changes make automated certificate lifecycle management essential rather than optional. Browser handling of revocation varies, but accurate revocation information remains central to PKI trust, and it depends on the same discipline applied to TLS certificates throughout their life.
Common Mistakes and Real-World Challenges
Many organizations default to unspecified for almost every revocation. That is technically valid for private PKI, but it strips out the context that makes investigations, reporting, and automation effective, and for public TLS it is not even permitted.
Another frequent issue is misunderstanding certificateHold. It was designed for temporary suspension rather than permanent revocation, and although RFC 5280 defines it, it is uncommon in modern environments and disallowed for public TLS. Teams also confuse CRLReason with ReasonFlags, which leads to wrong assumptions about how revocation information is distributed and processed.
In regulated environments, inconsistent use of reason codes creates audit problems, because an investigator cannot tell whether a certificate was revoked due to a security incident or a routine administrative change.
Security Best Practices
Revocation deserves to be treated as a core part of certificate lifecycle governance, not a compliance checkbox. When revoking certificates, a few habits keep the data trustworthy and useful.
- Use the most accurate reason available, and for public TLS omit the reasonCode rather than defaulting to unspecified.
- Document procedures for compromise-related revocations, so keyCompromise is applied consistently and quickly.
- Maintain audit trails for every revocation action.
- Protect CA signing keys with strong controls, using a FIPS 140-3 Level 3 validated Hardware Security Module where appropriate. Encryption Consulting’s key management and HSM services can help organizations select, deploy, and operate the right HSM infrastructure for their PKI environment.
- Monitor CRL and OCSP publication so revocation information stays available to relying parties.
Accurate revocation metadata strengthens both security operations and compliance reporting, and it helps teams respond faster when a certificate-related incident occurs.
How Encryption Consulting Can Help
Managing certificate revocation across a large estate gets harder when an organization runs multiple Certification Authorities, certificate types, and trust domains. Encryption Consulting helps design, deploy, and manage scalable PKI through its Enterprise PKI Services, covering certificate lifecycle governance, revocation workflows, CA architecture reviews, compliance alignment, and operational best practices, so revocation supports both security and business goals.
For day-to-day operations, CertSecure Manager provides centralized visibility into certificate inventories, expiration events, automated renewal workflows, and the health of revocation endpoints (CRL and OCSP) across the enterprise. As publicly trusted validity periods continue to shrink toward 47 days, that automation becomes the difference between routine renewals and avoidable outages.
Whether the goal is modernizing an existing PKI or building a new trust architecture, Encryption Consulting can help establish revocation processes that are secure, auditable, and operationally efficient.
Conclusion
CRL reason codes look like a small detail, but they explain why certificates are revoked and how an organization should respond. The most important distinction to remember is that CRLReason identifies why a specific certificate was revoked, while ReasonFlags identifies which revocation reasons a CRL distribution point covers. Confusing the two leads to mistakes in PKI design, troubleshooting, and policy.
As organizations automate more of the certificate lifecycle, accurate revocation information becomes more valuable for security operations, auditing, compliance, and incident response. Used well, CRL reason codes turn revocation from a simple status check into a meaningful part of trust management. A practical first step is to standardize which reason codes your teams use and confirm they align with both RFC 5280 and the policies governing your public certificates.
