At midnight UTC on a Saturday, the certificate on a payment company's partner API expires. Integrations start failing within minutes, and the on-call engineer finds that the renewal reminder went to someone who left the company in the spring. Nothing was attacked. A certificate simply reached the end of a life cycle nobody was tracking.
On the CompTIA Security+ SY0-801 exam, the certificate life cycle sits under objective 1.3, which expects you to explain why choosing the right cryptographic solution matters, including generating a certificate signing request (CSR), certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP). This lesson follows one certificate from key generation through the CSR, validation, issuance, installation and renewal to revocation and expiration, then compares the ways clients check whether a certificate has been revoked.
Every certificate starts with a key pair the requester generates
The life cycle begins before the CA is involved. The administrator generates a key pair on the system that will use it, or inside a hardware security module (HSM). The private key should never leave that system. If a vendor or website offers to generate the key for you and send it over, someone else has held a copy of your private key, and you can't prove what happened to it.
For a public web server, the common choices are an ECDSA key on the P-256 curve, which is small and fast, or an RSA key of at least 2,048 bits, with 3,072 bits for keys that must last a long time. With OpenSSL:
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out www.example.com.key
chmod 600 www.example.com.key
That key file isn't encrypted, so file permissions are what protect it; the chmod limits it to its owner. On Windows, the key is created in the computer's key store when you build the request in IIS Manager or with certreq, and you can mark it non-exportable so it can't be copied off the machine.
A CSR carries the public key and the requested names, never the private key
A certificate signing request, in the PKCS #10 format, is what you send to the CA. It contains the public key, the subject's distinguished name and any requested extensions such as the SAN list. The requester signs the CSR with the private key, which proves to the CA that the requester actually holds the key matching the public key inside.
openssl req -new -key www.example.com.key -out www.example.com.csr \
-subj "/C=US/ST=Texas/L=Austin/O=Example Retail Inc/CN=www.example.com" \
-addext "subjectAltName=DNS:www.example.com,DNS:example.com"
Each part of the subject has a meaning a CA will check:
- C is the two-letter ISO country code, so US, not USA.
- ST is the state or province, spelled out in full.
- L is the locality, usually the city.
- O is the organization's exact legal name. OV and EV CAs verify it against business records.
- CN is the common name, traditionally the main hostname. Browsers no longer use it for matching.
- subjectAltName lists every hostname the certificate must cover. A name missing here becomes a name mismatch error later.
Older guides also show OU, the organizational unit. Public CAs stopped including it in TLS certificates in 2022, so leave it out of public requests.
Before submitting, check the CSR:
$ openssl req -in www.example.com.csr -noout -text -verify
Certificate request self-signature verify OK
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C=US, ST=Texas, L=Austin, O=Example Retail Inc, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
Signature Algorithm: ecdsa-with-SHA256
The first line confirms the CSR's signature matches its own public key. The CSR isn't secret; it is a block of text beginning with BEGIN CERTIFICATE REQUEST that you paste into the CA's order form. It is also only a request. For a domain validated certificate the CA discards the country, state, city and organization and issues a certificate containing just the hostnames.
On the exam, any answer that has the private key traveling to the CA is wrong. The CSR carries the public key; the private key stays home.