Issuing, renewing, and revoking certificates

Requesting a certificate

The clinic's certificate for portal.harborclinic.example started with a key pair generated on the clinic's side. The private key never leaves the clinic. To ask a CA for a certificate, the clinic creates a certificate signing request (CSR) containing the public key and the names it wants, and signs the request with the private key. That signature shows the CA that the requester holds the key it is asking the CA to vouch for.

With OpenSSL 3, a key and request for the portal could be created like this:

openssl req -new -noenc \
  -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
  -keyout portal.key -out portal.csr \
  -subj "/CN=portal.harborclinic.example" \
  -addext "subjectAltName=DNS:portal.harborclinic.example,DNS:login.harborclinic.example"

The -noenc option writes the private key without a passphrase, so portal.key needs the protection described in Storing and using keys. In practice, most servers use automated clients or key hardware that generate the key and request without anyone handling the file.

Proving control of a name

Before signing, the CA must decide whether the requester is entitled to the names in the request. This is the CA's version of identity proofing. The claim is "we control portal.harborclinic.example," and for a domain-validated certificate the CA checks exactly that, much as email verification checks access to a mailbox.

Automated issuance protocols such as ACME give the requester a random token and ask it to place that token where only the domain's controller could. One method serves the token from the site over HTTP:

GET http://portal.harborclinic.example/.well-known/acme-challenge/k3Qx9vTzR2mW

Another publishes it in DNS, which also works for wildcard names and servers that are not reachable from the internet:

_acme-challenge.portal.harborclinic.example.  300  IN  TXT  "hG7pL2sQv9dXcR4nTbW8yZ1mK5aE3fJ0uOiN6rYtS2c"

If the CA finds the expected value, it issues the certificate. Like the address confirmation in Proofing methods, this shows control at the time of the check, not a lasting truth. Anyone who takes over the clinic's DNS or web server, even briefly, can pass the same check. Checking from several network locations makes that harder, and a CAA record in DNS lets the clinic name the CAs permitted to issue for its domain, so other CAs refuse:

harborclinic.example.  3600  IN  CAA  0 issue "ca.example"

Certificates that include an organization's name need more: the CA also validates the organization through registration records and contact checks, closer to the document and record checks used for people.

Renewing before expiry

Every certificate expires, and the maximum lifetime of publicly trusted certificates has been shrinking. Shorter lifetimes limit how long a mistaken or compromised certificate remains usable, and reduce reliance on revocation. They also make manual renewal impractical.

An expired certificate is one of the most common causes of avoidable outages. Nothing is wrong with the server except a date, yet every client refuses to connect. The reliable approach is automation: a client on the server requests a new certificate well before expiry, proves control of the name again, installs the result, and reloads the server. Many clients generate a fresh key pair at each renewal, so each key is used for a limited time.

Automation needs watching. The clinic keeps an inventory of its certificates and monitors their expiry dates independently of the renewal client, so a renewal that fails quietly becomes an alert rather than an outage. Certificate Transparency monitoring, described in Certificate authorities and chains, also shows every certificate issued for its names.

Revoking a certificate

Suppose a developer accidentally commits portal.key to a public code repository. Deleting the file does not help; anyone could already have copied it, and with it they could impersonate the portal to anyone who connects to their server.

The clinic generates a new key pair, obtains a new certificate, and deploys it. Then it asks the CA to revoke the old certificate, giving key compromise as the reason. The CA publishes the revocation, and clients that check revocation stop accepting the old certificate. As Validating a certificate explained, not every client will notice, which is one more reason short lifetimes matter. CAs also revoke certificates on their own when they discover they issued one incorrectly, or when the holder no longer controls the name.

A clinic that renews automatically is well placed to handle this. Replacing a certificate is already routine, so an emergency replacement uses the same process at an unplanned time.

Trust from end to end

Follow Alex's next visit to the portal. The browser validates the clinic's certificate against a root it trusts, and the server proves it holds the matching private key. Alex signs in with a passkey whose public key the portal stored at enrollment. The clinic's sign-in service signs a token with a key held in hardware, and the portal checks it against the clinic's published key set, fetched over that same kind of validated HTTPS connection. The results it shows were signed by the lab.

Each of those steps rests on an earlier decision: the proofing that linked Alex's account to the right record, the enrollment that registered Alex's passkey, the CA's check of the clinic's domain, and the platform's choice of trusted roots. The Authentication methods and MFA lessons and the OAuth and OpenID Connect lessons build on these foundations, following how signed tokens and verified keys carry trust between systems.