Certificate Lifecycle Stages — From Request to Revocation

Key Takeaways

The six stages are: Request → Validation → Issuance → Deployment → Monitoring → Renewal/Revocation

Most outages happen in the gaps between stages — cert issued but never deployed, or renewed but service not reloaded

Automation (ACME, cert-manager) collapses stages 1-4 into a single operation, eliminating human error

Monitoring is the only stage that runs continuously — everything else is event-driven

The certificate lifecycle is the sequence of stages every digital certificate passes through, from initial request to eventual expiration or revocation. Understanding these stages matters because outages rarely happen because a certificate doesn’t exist — they happen because something broke between stages. A certificate was issued but never installed. A renewal succeeded but the service wasn’t reloaded. Monitoring covered production but missed the staging wildcard.

Why it matters

Ownership clarity — each stage has a different responsible party (requester, CA, platform team, security team). Gaps between owners cause failures.
Automation targeting — you can’t automate what you haven’t mapped. Identifying stages reveals which are manual and which can be eliminated.
Audit trail — compliance frameworks (PCI DSS, SOC 2) require evidence of certificate management. The lifecycle defines what to log.
Failure isolation — when a cert-related outage occurs, knowing the stages lets you pinpoint where the process broke (issuance? deployment? monitoring?)
Renewal planning — certificates with 90-day validity (Let’s Encrypt) cycle through stages 12x per year. Manual processes don’t survive that frequency.

How it works

Stage 1: Request (CSR Generation)

The process begins when someone or something needs a certificate. A private key is generated, and a Certificate Signing Request (CSR) is created containing the public key, domain name(s), and organization details. In automated flows, this happens programmatically. In manual flows, an engineer runs openssl req or fills out a web form.

Stage 2: Validation

The CA verifies the requester’s authority over the domain. For DV certificates, this means an HTTP-01 challenge, DNS-01 TXT record, or email confirmation. For OV/EV, it includes business identity verification. ACME automates DV validation entirely.

Stage 3: Issuance

The CA signs the public key from the CSR with its intermediate CA private key, producing the certificate. The certificate includes validity dates, SANs, key usage extensions, and the CA’s signature. This stage is instantaneous for DV (seconds via ACME) or days for EV (manual review).

Stage 4: Deployment

The issued certificate and its private key are installed on the target system — a web server, load balancer, API gateway, or container. This is where the certificate becomes operational. Deployment includes configuring the full chain (end entity + intermediate) and reloading the service to pick up the new files.

Stage 5: Monitoring

Continuous tracking of certificate health: expiration dates, chain validity, protocol compliance, and revocation status. This is the only stage that runs persistently. Everything else is event-driven.

Stage 6: Renewal or Revocation

Before expiry, the certificate is renewed (repeating stages 1-4). If compromised, it’s revoked — the CA publishes the serial number to CRL/OCSP, and clients stop trusting it. Revocation is immediate; renewal should happen 30+ days before expiry.

In real systems

ACME automated flow (Let’s Encrypt + certbot): Stages 1-4 collapse into a single command. Certbot generates the key, creates the CSR, completes the HTTP-01 challenge, retrieves the certificate, installs it, and reloads Nginx. A cron job handles renewal. The entire lifecycle is automated except monitoring (which certbot doesn’t do).

cert-manager in Kubernetes:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
spec:
  secretName: api-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - api.example.com

cert-manager handles request, validation, issuance, deployment (into a K8s Secret), and renewal automatically. It monitors expiry and triggers renewal 30 days before. The Ingress controller picks up the new Secret without manual intervention.

Manual enterprise flow: An engineer submits a request through a ticketing system. A PKI admin validates and approves. The CA issues the certificate. The engineer downloads it, copies it to the server, updates the config, and reloads the service. A spreadsheet tracks expiry dates. This process has a failure point at every stage transition.

Where it breaks

Gap between issuance and deployment — the certificate is issued and sitting in someone’s email or a downloads folder, but never installed on the server. The old certificate expires, the service goes down, and the team discovers the new cert was issued three weeks ago but never deployed. This is the most common failure in manual workflows.

Monitoring blind spot — monitoring covers the primary domain certificates but misses internal services, wildcard certs deployed on non-standard ports, or certificates managed by a different team. The certificate that expires and causes an outage is always the one nobody was watching.

Renewal without reload — automation renews the certificate files on disk (certbot writes new PEM files), but the web server keeps serving the old certificate from memory. Without a post-renewal hook that runs nginx -s reload or systemctl reload apache2, the renewed certificate is never actually used. The service appears healthy until the old in-memory cert expires.

Operational insight

The 90-day certificate validity that Let’s Encrypt popularized was intentionally designed to force automation. At 90 days, manual renewal is technically possible but operationally unsustainable at scale. Organizations that adopt short-lived certificates without first automating stages 1-4 end up with more outages, not fewer. The correct sequence is: automate first, then shorten validity. Never the reverse.