The Certificate Lifecycle: Issuance, Renewal, and Revocation
The first part of this series laid out the anatomy of a modern PKI: the roots, the issuing CAs, the trust stores, the cryptographic primitives that make any of it meaningful. That article was about structure. This one is about motion. A certificate isn't a static artefact. It has a life, and that life has a shape.
In my experience, most PKI pain is not crypto pain. RSA moduli do not get factored over the weekend. What actually takes systems down is a certificate that nobody renewed, a key that lived somewhere it should never have lived, or a revocation check that silently failed open. The mathematics is the easy part. The lifecycle is where the operational risk concentrates.
So I'll treat a certificate as what it really is, a state machine, and walk through every transition and where the operational risk sits in each.
A certificate is a state machine
A certificate occupies exactly one well-defined state at any moment, and every state change is an event that can be observed, automated, and alarmed on. The trouble starts when teams treat issuance as a one-off ticket and then lose sight of the certificate until something breaks.
enroll / CSR
+------------+ submit +------------+ CA validates & signs
| REQUESTED | --------> | PENDING | --------------------+
+------------+ +------------+ |
^ v
| rekey / new CSR +------------+
| | ISSUED |
| +------------+
| |
| install / deploy
| v
+-----------+ renew (T-N days) +----------+ +------------+
| RENEWING | <------------------- | ACTIVE | ---> | (in use) |
+-----------+ +----------+ +------------+
| | |
| new cert issued | | compromise / decommission
v | v
(back to ACTIVE) | +-----------+
| | REVOKED | (CRL / OCSP)
notAfter | +-----------+
reached v
+-----------+
| EXPIRED | (terminal)
+-----------+Two of those states, EXPIRED and REVOKED, are terminal, and lifecycle management is mostly about controlling which terminal state you reach and when. Reaching REVOKED deliberately is governance. Reaching EXPIRED by accident is an outage. The difference between a mature PKI practice and an immature one is almost entirely about how reliably the ACTIVE → RENEWING → ACTIVE loop executes without human heroics.
Enrolment: where keys are born and what the CA actually checks
The lifecycle begins before the CA is ever involved, and this is the step most often gotten wrong. The private key should be generated on the system that will use it, and it should never leave that system. Not over email, not in a shared drive, not in a ticket attachment. A key that has travelled is a key that can no longer be reasoned about. When a .pem file is being moved around, that is the moment to ask why the key wasn't born where it lives.
The subject never sends the key to the CA. It sends a Certificate Signing Request, a PKCS#10 structure (defined in RFC 2986) carrying the public key, the requested subject and attributes, and a signature made with the corresponding private key. That self-signature is the proof-of-possession: it demonstrates to the CA that the requester actually holds the private key matching the public key being certified, without the private key ever being disclosed.
# Generate a 3072-bit RSA private key (kept local, mode 0600)
openssl genpkey -algorithm RSA \
-pkeyopt rsa_keygen_bits:3072 \
-out service.example.com.key
chmod 600 service.example.com.key
# Create a PKCS#10 CSR, with SANs supplied inline (OpenSSL 3.x)
openssl req -new \
-key service.example.com.key \
-out service.example.com.csr \
-subj "/C=GB/O=Example Org/CN=service.example.com" \
-addext "subjectAltName=DNS:service.example.com,DNS:www.service.example.com" \
-addext "keyUsage=critical,digitalSignature,keyEncipherment" \
-addext "extendedKeyUsage=serverAuth"
# Verify the CSR locally before submission: confirm the signature
# (proof-of-possession) and inspect the requested fields.
openssl req -in service.example.com.csr -noout -verify -textThe Common Name is now largely vestigial for server certificates. Relying parties consult the subjectAltName extension, and the CA/Browser Forum Baseline Requirements have mandated SANs for years. Tooling that still relies on CN matching is overdue an upgrade.
Validation: what DV, OV and EV actually prove
Once the CSR arrives, the CA's job is to validate the request against the assurance level being purchased. There are three tiers, and they prove different things, though the distinction is often muddied by the assumption that a green padlock is a green padlock.
- Domain Validation (DV) proves one thing only: that the requester controls the domain. Control is demonstrated by an automatable challenge: a DNS TXT record, a file served over HTTP, or an email to a well-known address. DV says nothing about who the operator is. For the vast majority of TLS endpoints this is a sensible default, and it is exactly the level ACME automates so well (the subject of Part 3).
- Organisation Validation (OV) adds a vetting step: the CA confirms the requesting organisation is a real, registered legal entity and that the applicant is associated with it. The organisation's identity is embedded in the certificate. It belongs where you want some accountability behind the certificate, such as internal services, partner integrations and regulated contexts.
- Extended Validation (EV) applies the most rigorous identity vetting under the CA/Browser Forum guidelines. Its practical value has eroded sharply since browsers stopped giving it special UI treatment, but it still has a place where a strong, externally-attested legal identity is a contractual or regulatory requirement.
My pragmatic line: use DV everywhere issuance can be automated, reserve OV for things humans and partners need to trust by name, and treat EV largely as a compliance instrument rather than a day-to-day security control. Choosing a higher tier "to be safe" often buys little more than a slower, manual issuance path, and as we will see, that is itself a common cause of outages.
Issuance and profiles: enforce consistency at signing time
When the CA signs, it does not simply rubber-stamp whatever the CSR asked for. A well-run CA applies a certificate profile (template) that constrains and overrides the request: the validity period, the permitted key usages and extended key usages, the name constraints, the inclusion of CRL distribution points and OCSP responder URLs, and the acceptable key types and sizes.
This matters because the CSR is attacker- and accident-influenced input. The requester can ask for a ten-year validity, a wildcard SAN, or keyCertSign in the key usage, and a CA that honours those requests blindly is a liability. The profile is the policy enforcement point.
A certificate profile is policy expressed as configuration. If you cannot point to the template a certificate came from, you are not running a PKI. You are running a signing oracle.
Concretely, a server-TLS profile should pin extendedKeyUsage to serverAuth, force keyUsage to digitalSignature, keyEncipherment, cap validity at whatever the current Baseline Requirements permit, and reject keys below the minimum strength. Get this right once, at the template level, and every certificate that flows through it is consistent by construction rather than by reviewer diligence.
Renewal, rekey and reissue: the distinctions that matter
These three words are used interchangeably in conversation and they should not be, because operationally they are different events with different risk profiles.
- Renewal: a new certificate with a fresh validity window, conceptually continuing the same identity. In the loosest usage it may reuse the existing key pair.
- Rekey: a renewal that also generates a new key pair. A new CSR, a new private key, a fresh proof-of-possession.
- Reissue: replacing a certificate within its existing validity period, typically because something in it was wrong: a bad SAN, a compromised key, a profile change.
Why "renew early, rotate the key" is the right default
The naive approach renews on or near expiry and reuses the same key "because nothing changed". Both halves of that are worth reconsidering.
Renew early, well before notAfter, so that a failed renewal is a warning with days of headroom, not an outage in progress. I recommend renewing at, say, two-thirds of the validity period, leaving a generous window to detect and retry failures before anything actually expires.
And rotate the key on every renewal as a matter of course. A key pair's exposure to compromise grows monotonically with its lifetime and its number of deployments. When rekey is the default, key rotation costs nothing extra operationally (it is just what renewal does), and the team is never in the position of discovering that a single long-lived key underpins half the estate. Reusing keys to save effort is a false economy. The only effort it saves is effort that should have been automated anyway.
Revocation done properly, and the case for not needing it
Sometimes you must declare a still-valid certificate untrustworthy before it expires: a key compromise, a mis-issuance, a decommissioned service. That is revocation, and the mechanisms for publishing it are where a great deal of architectural argument lives.
CRLs vs OCSP vs stapling
- CRLs (RFC 5280). The CA periodically publishes a signed list of revoked serial numbers. Simple and robust, but the lists grow large and relying parties may cache a CRL for hours, so revocation is not timely. They scale poorly as a real-time check.
- OCSP (RFC 6960). The relying party asks an OCSP responder about one specific certificate and gets a signed
good,revoked, orunknown. Timelier and lighter per query, but it puts the responder on the critical path of every connection and leaks browsing patterns to the CA. - OCSP stapling (RFC 6066). The server fetches its own OCSP response periodically and presents ("staples") it in the TLS handshake. This removes the per-client round-trip to the CA and the privacy leak. It is generally the preferred approach when live revocation checking is required at all.
The fatal flaw running through all of this is soft-fail. Because an unreachable responder must not break the whole web, clients overwhelmingly treat "couldn't check" as "probably fine" and proceed. An attacker who can block the revocation check (exactly the network position an attacker exploiting a stolen key would hold) simply suppresses the response. Soft-fail revocation is, against a capable adversary, closer to theatre than control.
# Query an OCSP responder for the status of a single certificate.
# We need the certificate, its issuer, and the responder URL.
# Pull the responder URL straight out of the certificate (AIA extension):
openssl x509 -in service.example.com.crt -noout -ocsp_uri
# -> http://ocsp.example-ca.net
openssl ocsp \
-issuer issuing-ca.crt \
-cert service.example.com.crt \
-url http://ocsp.example-ca.net \
-no_nonce -resp_text
# Expected (abridged) response:
# service.example.com.crt: good
# This Update: Feb 11 09:00:00 2026 GMT
# Next Update: Feb 12 09:00:00 2026 GMTThe architectural pivot: short-lived certificates
Many practitioners arrive at the same pragmatic conclusion: one of the most effective revocation strategies is to need revocation as little as possible. If a certificate lives for days rather than a year, its validity window is its revocation mechanism. A compromised key stops mattering shortly after compromise, because the certificate expires on its own and the next short-lived cert is issued from a fresh key. The window of exposure shrinks to the lifetime of the certificate.
Short-lived certificates trade a hard, fragile, soft-failing distributed check for a soft, reliable, local one: just keep reissuing. The catch, and it is the whole catch, is that this is only viable if issuance and deployment are fully automated. A certificate cannot be rotated every few days by hand. That brings us to the pressure the industry is now applying to everyone.
The expiry outage, and why the clock is being turned down
The single most common, most embarrassing PKI incident is the expiry outage: a certificate hits notAfter, handshakes start failing, and an organisation discovers in real time that the renewal process was a person who has since changed roles and a reminder in a calendar nobody owns. Most of us have seen a team rediscover, under pressure, that a certificate everyone had forgotten about was load-bearing.
This anti-pattern was survivable when certificates lasted two or three years, because the failure was rare enough to muddle through manually. That era is ending. The CA/Browser Forum has been steadily ratcheting maximum validity downward, and an agreed, phased schedule takes public TLS certificates toward a 47-day maximum validity by 2029. A certificate that must be replaced every six or seven weeks cannot be managed by a human and a spreadsheet. The maths does not work across a real estate of hundreds or thousands of endpoints.
That looks deliberate. Shrinking validity forces the issue: manual lifecycle management becomes untenable, and automation stops being a nice-to-have and becomes the only sane operating model. The lifecycle described here (enrol, validate, issue against a profile, renew early, rekey by default, expire rather than revoke) suits that world well. The remaining question is how to make it run without humans in the loop. That is where the series goes next, with ACME: the protocol that turns this entire state machine into something a machine drives end to end.
NK