Certificate Lifecycle and Revocation

Every digital certificate follows a defined lifecycle from creation to retirement. The stages are: Request and Enrollment (generate key pair, create CSR), Issuance (CA validates and signs), Deployment (install on server or device), Use (active operational period), Renewal (before expiry), and Revocation or Expiry (end of life). Managing this lifecycle at scale — especially in enterprises with thousands of certificates — requires automation and certificate lifecycle management (CLM) tools, as manual tracking inevitably leads to expired certificates causing outages.

The certificate lifecycle begins with a Certificate Signing Request (CSR). The requestor generates a key pair, then creates a CSR that contains the public key, subject information (CN, O, C), and is signed with the private key (proving ownership of the private key without revealing it). The CSR is submitted to the CA, which validates the requestor's identity and, if approved, signs the certificate. The private key never leaves the requestor's possession. CSR generation is the critical step where key strength is determined — using a minimum of 2048-bit RSA or 256-bit ECC.

Certificates must be renewed before their notAfter date expires. Best practice is to begin the renewal process at least 30 days before expiry (many organizations target 60-90 days). Renewal typically involves generating a new CSR and private key, submitting to the CA, and replacing the old certificate and key on all servers where it is deployed. Let's Encrypt automates this process using the ACME protocol — the certbot tool automatically renews certificates when they have less than 30 days remaining. Expired certificates cause browser errors that stop users from accessing services.

Certificate revocation is the process of invalidating a certificate before its scheduled expiry date. Reasons for revocation include: the private key was compromised (most urgent — immediate revocation required), the certificate was issued in error (wrong domain, wrong organization), the subject's information changed (company renamed, employee left), or the CA itself was compromised. Revocation is critical because browsers and systems that don't know a certificate is revoked will continue to trust it — giving an attacker in possession of the stolen private key an active MITM capability until the certificate expires or is known to be revoked.

A Certificate Revocation List (CRL) is a signed list published by a CA that contains the serial numbers of all certificates it has revoked that have not yet expired. Clients download the CRL, cache it, and check if a presented certificate's serial number appears on the list. CRLs have significant limitations: they can be very large (large CAs have millions of revoked certificates), clients often cache them for hours or days introducing lag, and downloading the full CRL for every connection is inefficient. CRLs are still used but increasingly complemented or replaced by OCSP.

OCSP (Online Certificate Status Protocol) provides real-time certificate revocation checking without requiring clients to download entire CRLs. The client sends a query to the CA's OCSP responder with the certificate's serial number. The responder replies with a signed response indicating the certificate is good, revoked (with revocation date and reason), or unknown. OCSP is faster and more timely than CRL, but every TLS connection requires an additional HTTP round-trip to the OCSP responder, adding latency. OCSP responses are signed by the CA to prevent tampering.

OCSP Stapling solves the latency problem of real-time OCSP checking. Instead of the client querying the CA's OCSP responder during each TLS handshake, the server pre-fetches its own OCSP response from the CA and 'staples' (attaches) it to the TLS handshake. The client receives a fresh, CA-signed OCSP response directly from the server — no additional round-trip required. The server refreshes its stapled OCSP response periodically (typically every hour). OCSP Stapling improves connection speed and reduces load on CA OCSP responders while maintaining revocation checking.

OCSP Must-Staple is an X.509 extension that tells browsers the server must provide a stapled OCSP response. Without it, browsers perform a 'soft fail' if the OCSP check fails — they allow the connection anyway (to prevent OCSP responder outages from blocking all TLS). An attacker can exploit soft-fail behavior by blocking the client's OCSP request, making it appear the certificate is still valid even after revocation. OCSP Must-Staple prevents this by requiring a valid stapled response; without it, the browser refuses the connection. Adoption remains limited due to deployment complexity.

Certificate revocation and certificate pinning address the same problem — trusting fraudulent certificates — but from different angles. Revocation (CRL/OCSP) is a reactive mechanism: the CA invalidates a certificate after a problem is discovered. Pinning is a proactive mechanism: the application refuses any certificate except a pre-approved one. Pinning provides stronger guarantees than revocation because it works even if the CA fails to revoke promptly, but introduces deployment rigidity. For the Security+ exam, know both mechanisms and understand that revocation is the standard PKI mechanism while pinning is an optional defense-in-depth measure.

When a certificate is revoked, the CA assigns a revocation reason code that helps clients and administrators understand why. Common reason codes defined in RFC 5280 include: keyCompromise (the private key was compromised), cACompromise (issuing CA was compromised), affiliationChanged (subject's organization changed), superseded (new certificate issued as replacement), cessationOfOperation (domain no longer active), and privilegeWithdrawn (entitlement revoked). The reason code appears in both CRL entries and OCSP responses, providing context for incident response teams investigating revocation events.

The ACME (Automatic Certificate Management Environment) protocol, used by Let's Encrypt, automates the entire certificate lifecycle. ACME clients (like certbot) automatically request, renew, and deploy certificates without human intervention. The CA uses domain validation challenges to confirm domain ownership: the HTTP-01 challenge requires placing a specific file at a known URL; the DNS-01 challenge requires creating a DNS TXT record. ACME has transformed certificate management — 90-day certificates from Let's Encrypt now power a large fraction of the internet's HTTPS traffic, all renewed automatically.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: the certificate lifecycle runs from CSR generation through issuance, deployment, and renewal or revocation; CRL provides batch revocation lists while OCSP provides real-time per-certificate status; OCSP Stapling eliminates the latency of real-time OCSP; and ACME (Let's Encrypt) automates the entire renewal lifecycle. Next up we explore PKI Use Cases.