Certificate Expiration: Still Needed?

TL;DR

Yes, you still need expiration times in certificates even if everyone checks for revocation. Expiration provides a crucial fallback mechanism and simplifies certificate management.

Why Certificates Expire (Even with Revocation)

Certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) are used to check if a certificate has been cancelled before its expiry date. However, relying *solely* on these systems isn’t enough. Here’s why expiration remains important:

1. Revocation System Failures

1. Availability: CRL distribution points or OCSP responders can go offline. If a check fails, applications may not know whether the certificate is valid or revoked. Expiration provides a guaranteed upper limit on validity.
2. Performance: Checking revocation status adds latency. Frequent checks can impact application performance. While caching helps, it’s not perfect.
3. CRL Size/OCSP Load: Large CRLs can be slow to download and process. OCSP responders can become overloaded with requests.
4. Stale Information: Revocation information isn’t always immediate. There’s a delay between certificate revocation and its appearance on CRLs or in OCSP responses.

2. Operational Simplicity

1. Automated Renewal: Expiration dates make automated certificate renewal easier. Systems can be configured to request new certificates before the old ones expire, minimizing downtime and manual intervention.
2. Key Compromise Mitigation: If a private key is compromised (even if not immediately detected), expiration limits the window of opportunity for attackers to use it. A shorter expiry time reduces risk.
3. Policy Compliance: Many security policies require certificates to have defined expiration dates as part of their overall certificate management practices.

3. Revocation is Not Always Guaranteed

While best practice dictates immediate revocation upon compromise, it doesn’t always happen.

• Lost Keys: If a private key is lost and the corresponding certificate isn’t revoked before expiry, it remains valid until its expiration date.
• Delayed Discovery: Compromises may not be detected immediately.

4. Practical Example

Imagine a scenario where a rogue employee steals a private key and uses the certificate for malicious purposes. If revocation checking fails (e.g., OCSP responder is down), an application relying solely on revocation would continue to trust the compromised certificate until it’s manually revoked, or the CRL updates. However, with expiration, the certificate will eventually become invalid regardless.

5. Certificate Lifespan Considerations

While expiration is necessary, the *length* of the lifespan should be carefully considered:

• Shorter Lifespans: Increase security (smaller window for compromise) but require more frequent renewal and management overhead.
• Longer Lifespans: Reduce management overhead but increase risk if a key is compromised.

Modern Certificate Authorities (CAs) are moving towards shorter certificate lifetimes (e.g., 398 days) to improve security and encourage automation.

Conclusion

Revocation checking is an important layer of cyber security, but it’s not a replacement for certificate expiration. Expiration provides a critical fallback mechanism, simplifies management, and reduces risk in scenarios where revocation systems fail or are delayed. Both mechanisms should be used together to ensure robust trust infrastructure.