Certificate Renewal and Revocation

Certificate renewal is the process of obtaining a new certificate before the current one expires, maintaining uninterrupted trust. Revocation is the process of invalidating a certificate before its natural expiry — declaring it untrustworthy immediately. Both are lifecycle endpoints, but they operate on fundamentally different timelines: renewal is planned and automated; revocation is reactive and urgent. The critical problem is that revocation doesn’t work reliably in practice — browsers fail open, meaning a revoked certificate often continues to be accepted.

Why it matters

• Renewal prevents outages — an expired certificate breaks every connection to your service. Automated renewal eliminates the most common cause of certificate-related downtime.
• Revocation limits breach exposure — when a private key is compromised, revocation is the only mechanism to stop an attacker from impersonating your service with the stolen key.
• Short validity forces renewal discipline — 90-day certificates (Let’s Encrypt) mean renewal must be automated. 397-day certificates (commercial CAs) still catch teams off guard.
• Compliance mandates revocation capability — PCI DSS, HIPAA, and SOC 2 require the ability to revoke compromised certificates within defined timeframes.
• Key rotation opportunity — renewal is the natural point to generate a new key pair, limiting the exposure window of any single private key.

How it works

Renewal flow:

1. Monitoring — track certificate expiry dates. Trigger renewal at 2/3 of lifetime (e.g., 60 days before expiry for 90-day certs).
2. Key decision — reuse existing key pair (faster, same CSR) or generate new key pair (better security, new CSR required).
3. CSR submission — send certificate signing request to the CA, either via ACME protocol or manual portal.
4. Validation — CA re-validates domain control (DV) or organization identity (OV/EV) depending on certificate type.
5. Issuance — CA signs and issues the new certificate with fresh validity dates.
6. Deployment — install the new certificate and reload the service. The old certificate remains valid until its original expiry.

Revocation flow:

1. Trigger — key compromise detected, domain ownership lost, employee with key access departs, or CA mis-issuance discovered.
2. Revocation request — certificate owner contacts CA (via ACME, portal, or API) with proof of ownership and reason code.
3. CRL update — CA adds the certificate serial number to its Certificate Revocation List, published at the CRL Distribution Point URL embedded in the certificate.
4. OCSP update — CA’s OCSP responder begins returning “revoked” status for that certificate’s serial number.
5. Client check — connecting clients query CRL or OCSP to verify the certificate hasn’t been revoked (in theory).

In real systems

Certbot renewal with hooks:

# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/bash
systemctl reload nginx
# Runs after successful renewal — ensures Nginx picks up the new cert

Certbot’s systemd timer runs certbot renew twice daily. It only acts when certificates are within 30 days of expiry.

OCSP stapling in Nginx:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/chain.pem;
resolver 8.8.8.8 valid=300s;
resolver_timeout 5s;

The server fetches the OCSP response from the CA and staples it to the TLS handshake. Clients get revocation status without contacting the CA directly — faster, more private, and doesn’t fail when the CA’s OCSP responder is down.

CRL publishing in Active Directory Certificate Services: AD CS publishes CRLs to LDAP and HTTP distribution points on a schedule (default: 1 week for base CRL, 1 day for delta CRL). Internal clients check these before accepting certificates for smart card login, VPN, or Wi-Fi authentication. If the CRL publishing server is unreachable and the cached CRL expires, all certificate-based authentication fails.

Kubernetes cert-manager renewal: cert-manager automatically renews certificates when they reach 2/3 of their lifetime. It creates a new CertificateRequest, obtains the cert, updates the Secret, and annotates the Certificate resource with the new expiry. No manual intervention required — but you need deploy annotations or pod restarts to pick up the new Secret.

Where it breaks

OCSP responder down + browser soft-fail — when a browser can’t reach the CA’s OCSP responder (network issue, responder overloaded, firewall blocking), it fails open — accepts the certificate anyway. This means a revoked certificate continues working for any client that can’t reach the OCSP responder. Chrome doesn’t even check OCSP for most certificates (it uses CRLSets instead, which cover only a subset of revocations). Firefox checks OCSP but soft-fails. The result: revocation is advisory, not enforced.

CRL too large to download — CRLs grow with every revocation and are never pruned until the CA issues a new base CRL. Large CAs accumulate CRLs of several megabytes. Clients on slow connections or constrained devices (IoT, embedded) time out downloading the CRL and either fail open (accept the cert) or fail closed (reject everything). Delta CRLs help but add implementation complexity that many clients don’t support.

Operational insight

The real-world answer to broken revocation is short-lived certificates. If a certificate is valid for only 24 hours (as some internal PKIs now issue), the maximum exposure window after key compromise is 24 hours — regardless of whether revocation infrastructure works. This is why Let’s Encrypt chose 90 days and is moving toward even shorter lifetimes. For internal services using private CAs like step-ca, you can issue certificates valid for hours. The tradeoff: your renewal automation must be bulletproof, because there’s no grace period. A renewal failure at 3 AM means an outage at 4 AM. Short-lived certificates don’t eliminate revocation — they make it less critical by bounding the damage window.

Related topics

• Certificate Lifecycle Stages
• What is ACME Protocol
• What is a Certificate Authority
• Root CA vs Intermediate CA
• What is Certificate Discovery