A decommissioned server is still running an old TLS certificate. An employee who left three months ago still has a valid client certificate because it was never revoked. A private key may have been exposed during a cloud migration, yet the associated certificate still shows a clean “not yet expired” status. These are routine failures in how organizations think about certificate validity, and they share a common root: treating expiry and revocation as interchangeable when they are not.
Certificate expiry and certificate revocation are distinct mechanisms, defined separately in RFC 5280, that serve different purposes in the X.509 trust model. Certificate expiry is a scheduled event written into the certificate at issuance time. Certificate revocation is a deliberate act by the issuing CA, triggered by a specific condition that makes the certificate untrustworthy before its scheduled end date.
Conflating the two leads to real gaps: organizations that manage renewal calendars carefully but have no coherent revocation policy, or teams that revoke certificates after a key compromise but have no visibility into which endpoints are still presenting them.
The consequences are not abstract. On February 3, 2020, Microsoft Teams went offline for nearly three hours after an authentication certificate expired without renewal. Microsoft’s own status post confirmed the cause: “an authentication certificate has expired, causing users to have issues using the service.” On August 19, 2020, Spotify users were disrupted for approximately an hour when a wildcard TLS certificate expired, taking streaming services offline. Both incidents were preventable. Neither required a sophisticated attack. They required only that no one was watching the expiry date.
This blog covers what each mechanism means, what distinguishes them, and what a functional certificate lifecycle requires from both.
What Certificate Expiry Means
Every X.509 certificate contains a validity field with two subfields: notBefore and notAfter. These are set at issuance and are embedded in the certificate itself. The notBefore field marks when the certificate becomes active. The notAfter field marks when it stops being accepted. Once the system clock passes the certificate’s notAfter timestamp, any conforming relying party rejects the certificate automatically, without any signal from the CA, without checking any external service, and without any human intervention.
That automatic rejection is the core value of expiry. It is a hard, local, passive boundary on trust. A TLS client checks the system clock against the notAfter field and makes its decision entirely on its own. There is no network call, no dependency on a running server, and no freshness concern. The mechanism cannot fail due to infrastructure downtime because it has no infrastructure.
Per RFC 5280, these dates are encoded as UTCTime for dates through 2049 and as GeneralizedTime for dates in 2050 or later. For certificates intended to carry no defined end date, such as some device identity certificates, RFC 5280 specifies the GeneralizedTime value 99991231235959Z. These certificates are effectively non-expiring for operational purposes. Unless something actively ends their trust, they remain valid for far longer than any realistic system or deployment lifecycle.
The limitation of expiry is precisely its passivity. It does not respond to events. If a private key is stolen on day ten of a one-year certificate’s life, the certificate remains valid from the relying party’s perspective for the remaining 355 days. Nothing about the notAfter field reflects that the underlying trust has already been broken. Expiry manages scheduled end-of-life. It has no mechanism for handling unscheduled loss of trust.
What Certificate Revocation Means
Revocation is the CA’s declaration that a certificate is no longer trustworthy before its notAfter date. It is an active, deliberate act. The Certificate Authority (CA) marks the certificate as invalid, and that information is then communicated to relying parties through one of two mechanisms: a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).
RFC 5280 defines two revocation states. The first is “revoked,” which is permanent and irreversible. Once a certificate is revoked, it stays revoked. The second is “certificateHold,” a temporary suspension that can be lifted. Hold is rarely used in practice and carries limited security utility because a relying party cannot know when or whether it will be lifted.
RFC 5280 defines ten reason codes that a CA can attach to a revocation entry: unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), and aACompromise (10). Note that value 7 is not used. These reason codes are not just administrative labels. They carry operational meaning.
The keyCompromise code signals that the private key was exposed. Under the CA/Browser Forum Baseline Requirements, a publicly trusted TLS certificate must be revoked within 24 hours of confirmed key compromise. The affiliationChanged or superseded codes apply when a certificate holder’s identity or role has changed, not because the key was compromised, but because the binding is no longer accurate.
Revocation is the mechanism that responds to events. Understanding when to use each revocation state matters in practice. Permanent revocation, the “revoked” state, applies whenever the underlying reason is definitive and irreversible. A private key confirmed as compromised must be permanently revoked: there is no scenario in which that key becomes trustworthy again. The same applies when an employee leaves the organization, when a system is decommissioned, or when a certificate is misissued. In all of these cases, the identity binding the certificate no longer exists, and restoring the certificate would serve no legitimate purpose.
The “certificateHold” state covers a narrower and genuinely temporary set of circumstances. Consider a device that has been reported stolen but is later recovered intact, with the private key confirmed unaccessed. Or a certificate bound to a service account that is being migrated to a new system, where operations are paused for a defined window, and the same certificate will resume use once the migration completes. Hold is the correct choice when the condition causing concern is reversible, and the organization expects to reinstate the certificate.
It is the wrong choice when the condition is security-driven and permanent, for example, using hold instead of the revoked state, because revoking feels drastic, or because re-issuing is inconvenient. That misuse of hold leaves a potentially compromised certificate in a reinstatable state, which is precisely the exposure revocation is designed to close.
Where expiry handles scheduled end-of-life, revocation handles every scenario where trust ends before the schedule does.
How Revocation Status Gets Communicated
Revoking a certificate at the CA does nothing for relying parties unless that status is communicated and checked. Two mechanisms exist for this.
Certificate Revocation Lists (CRLs), defined in RFC 5280 Section 5, are CA-signed files containing the serial numbers of certificates revoked by the issuing CA. A relying party downloads the CRL, checks whether the certificate’s serial number appears in it, and proceeds accordingly. CRL entries are not removed when a certificate expires. Per RFC 5280 Section 3.3, an entry must remain on the CRL until it appears on at least one regularly scheduled CRL published after the certificate’s expiry date. This ensures that a certificate revoked shortly before expiry is not quietly dropped from the list before clients have had a chance to receive the updated CRL.
CRLs have a propagation lag. A CA publishes a new CRL on a schedule, typically every 24 to 72 hours, for many enterprise CAs. A certificate revoked immediately after one CRL publication will not appear to relying parties until the next one is published and fetched. During that window, a revoked certificate may still pass CRL checks. CRLs also grow over time as more certificates are revoked, adding to the download overhead for clients.
OCSP (Online Certificate Status Protocol), defined in RFC 6960, addresses the scaling problem by making revocation checking per-certificate and on-demand. A client sends a request containing the certificate’s serial number to an OCSP responder. The responder returns one of three statuses: good, revoked, or unknown.
Good means no revocation record exists for that serial number within its validity period. It does not confirm that the certificate was legitimately issued. Revoked means the certificate has been revoked, typically with a reason code and a timestamp. Unknown means the responder cannot determine the certificate’s status, which may indicate the certificate was not issued by that CA.
In modern TLS deployments, OCSP Stapling allows a server to obtain and cache an OCSP response and attach it directly to the TLS handshake, reducing or eliminating the need for clients to query the OCSP responder themselves. This improves performance and mitigates the privacy concern of clients revealing their certificate validation activity to the CA. OCSP Stapling is defined in RFC 6066 through the TLS status_request extension and is supported in both TLS 1.2 and TLS 1.3 deployments.
The Core Difference in Practice
Expiry and revocation are not redundant. They address different failure modes.
- Expiry answers: “Has this certificate reached its scheduled end of life?” It enforces that boundary automatically, with no infrastructure, based only on the system clock and the notAfter field. It is reliable and passive. It does not respond to anything that happens during the certificate’s validity period.
- Revocation answers: “Has something changed since this certificate was issued that makes it untrustworthy?” It requires active CA action, communication infrastructure (CRL or OCSP), and relying parties that check. It is not passive. It can fail if the infrastructure is down, stale, or unreachable.
A certificate that has expired for a week is simply expired. Any client rejects it immediately, without question, without checking anything. A certificate revoked two days ago but not yet expired requires the relying party to check the CRL or OCSP, receive a revoked response, and act on it. If that check fails or is skipped, the certificate may still be accepted. That asymmetry is why revocation infrastructure quality matters. The mechanism only works when the infrastructure supporting it works.
Where Each One Breaks Down
Expiry fails when the validity period is too long relative to the trust it represents. A three-year certificate issued to an employee who leaves the organization in 90 days has more than 1,000 days of remaining validity, which no longer reflects any legitimate identity binding. The certificate was never revoked. It will continue passing expiry checks. If the employee retained access to the private key and the organization has no revocation checking, that certificate remains usable for nearly three more years.
Expiry also fails entirely for indefinite-validity certificates. A device certificate issued with the 99991231235959Z GeneralizedTime value has no expiry protection at all. If the device is decommissioned, the key is compromised, or the certificate is mis-issued, revocation is the only control available. There is no scheduled end date to rely on.
Revocation loses effectiveness when the supporting infrastructure is not maintained. A CA that has technically revoked a certificate but whose CRL distribution point URL is unreachable from the relevant network segment, or whose OCSP responder times out under load, has issued a revocation that no relying party can act on. The revocation exists in the CA’s database. It does not reach the systems that need to see it.
Revocation also becomes less critical as a compensating control for short-lived public certificates when checking is unreliable at scale. This is one of the motivations behind CA/Browser Forum Ballot SC-081v3, approved April 11, 2025, with 29 votes in favor, zero against, and five abstentions. The ballot reduces maximum public TLS certificate validity from 398 days to 200 days in March 2026, then to 100 days in March 2027, and finally to 47 days in March 2029.
With a maximum validity period of 47 days, an undetected key compromise has a bounded window regardless of whether revocation checking succeeds or fails. That rationale does not extend to private PKI, code signing, or IoT device certificates, which often carry multi-year validity periods and cannot use short validity as a substitute for functioning revocation infrastructure.
Why Both Must Work Together
Neither mechanism alone is sufficient. Expiry without revocation leaves a window of potentially years where a compromised or mis-issued certificate remains valid. Revocation without disciplined validity period management places the entire trust boundary on infrastructure that can become stale, unreachable, or neglected.
The two mechanisms are designed to complement each other. Expiry sets a hard outer limit on the trust window. Revocation provides the ability to close that window early when events require it. An organization that manages both effectively knows when each certificate it has issued will expire, maintains a revocation infrastructure that is actually reachable by the systems that need to check it, and has a policy that maps specific events, such as key compromise, employee departure, or system decommission, to a revocation action with a defined timeline.
For private PKI in particular, the absence of external enforcement from browser root programs or CA/B Forum requirements means the quality of both expiry management and revocation infrastructure is entirely a function of internal design choices. A private CA hierarchy that issues certificates without reachable CDP and AIA extensions, or without any OCSP responder, has no effective revocation mechanism regardless of what its configuration claims. The certificates look revocable on paper. They are not.
Understanding the distinction between expiry and revocation is not a theoretical exercise. It is the basis for knowing what an organization’s PKI can and cannot do when something goes wrong mid-lifecycle.
How Encryption Consulting Can Help
Encryption Consulting’s PKI Assessment is a structured engagement that evaluates your entire PKI environment across technical, operational, and governance dimensions. It begins with discovery: mapping your current PKI architecture across on-premises, cloud, and hybrid environments to establish a complete picture of what exists, how it is configured, and where it connects.
This includes CA hierarchy validation, certificate template review, key management practices, and an end-to-end test of your revocation infrastructure, verifying that CDP and AIA extensions in issued certificates point to responders and distribution points that are actually reachable from the network segments where certificates are validated.
From there, structured stakeholder workshops and architecture mapping sessions capture the operational reality behind the configuration. These sessions surface the gaps that documentation alone does not show: PKI infrastructure policies that exist on paper but are not enforced, OCSP responders that are technically deployed but untested under load, and certificate populations issued under templates that no longer reflect current security standards.
The output is a prioritized risk and gap analysis report. Findings are ranked by severity and mapped to specific remediation actions, giving your team a clear roadmap rather than a generic checklist.
CertSecure Manager
CertSecure Manager provides the operational layer that ties expiry tracking and revocation together on an ongoing basis. It maintains a live certificate inventory across public CAs, private CA hierarchies, HashiCorp Vault, and Microsoft PKI environments. Some of the key features of CertSecure Manager include:
- Centralized Certificate Inventory: Automatically discovers and inventories certificates across cloud, on-prem, and hybrid environments.
- Automated Lifecycle Management: Handles issuance, renewal, and revocation of certificates with minimal human intervention.
- Policy Enforcement Engine: Ensures compliance with enterprise security policies and industry standards.
- Role-Based Access Control (RBAC): Provides granular access management to ensure only authorized users can manage certificates.
- Integration With Leading CAs and DevOps Tools: Seamlessly integrates with public and private Certificate Authorities, as well as CI/CD pipelines.
- Real-Time Monitoring and Alerts: Offers dashboards and alerts for expiring or misconfigured certificates.
- Audit and Reporting: Maintains detailed logs and reports for compliance and forensic analysis.
Together, these capabilities give your team the visibility and control to manage certificate expiry and revocation not as reactive tasks, but as a continuous, auditable process.
Conclusion
Certificate expiry and revocation address different failure modes at different points in the certificate lifecycle. Expiry caps the total duration of trust and enforces that boundary automatically. Revocation handles the cases where trust is lost before the clock runs out. Both are necessary, and neither works reliably without attention to the infrastructure behind them.
As public TLS validity shortens under SC-081v3, the impact of revocation failures will diminish as certificate lifetimes shorten. For private PKI, code signing, and device certificates, that reality does not change.
For organizations looking to assess their current PKI posture, identify revocation infrastructure gaps, or strengthen certificate lifecycle management practices, a comprehensive PKI assessment and automated certificate lifecycle management platform can provide the visibility and control needed to manage certificates throughout their lifecycle.
Organizations that treat revocation as a secondary concern in long-lived certificate environments are assuming that nothing in their PKI estate will change before the notAfter date. That is not a security architecture. It is a calendar.
