From one certificate to an operating hierarchy
Understanding what fields sit inside a certificate, and how a chain of signatures walks back to a trusted root, is the X.509 module's job. This use case is the operational layer on top: how a real organization generates, protects, and rotates the keys that make that whole chain trustworthy in the first place — decisions that show up as concrete, auditable practices, not just protocol fields.
Why the root stays offline
A root CA's private key is the single highest-value target in the entire hierarchy: compromise it, and every certificate that chains back to it — potentially the trust anchor for an entire browser or operating system's certificate store — is suspect at once. Production CAs respond by keeping the root key air-gapped: generated once, used rarely (mainly to sign new intermediate certificates), and stored offline in a vault-controlled hardware security module that never touches a network.
Day-to-day certificate issuance runs through intermediate CAs instead, whose keys are online and actively used but individually far less catastrophic if compromised — an intermediate can simply be revoked and replaced by the still-safe offline root, exactly the blast-radius containment the root/intermediate split exists to provide.
Root CA
- •Kept offline, air-gapped, in an HSM
- •Used only rarely — mainly to sign intermediate certificates
- •Compromise is catastrophic: every downstream certificate is suspect
Intermediate CA
- •Online, used continuously for day-to-day issuance
- •Compromise is serious but contained — revoke it, and the root signs a replacement
- •This containment is the entire reason the split exists
Go deeperKey ceremonies: generating a root key under audit⌄
Because a root key's entire security rests on never being exposed even once, generating one isn't a routine engineering task — it's a scripted, multi-party "key ceremony," typically video-recorded and independently audited, where the HSM generates the key internally (it never exists outside the hardware boundary, even during creation) and multiple trusted individuals must jointly authorize any sensitive operation, echoing the threshold-of-trust idea from the Shamir's Secret Sharing use case elsewhere in this catalog.
Practice
A root CA's offline signing key requires 3 of 5 authorized ceremony participants to jointly authorize any use, following a Shamir threshold scheme. During a scheduled ceremony, 2 of the 5 participants are unreachable. Can the ceremony proceed with the 3 who are present?
Automated issuance: the ACME protocol
Manual certificate issuance doesn't scale to the volume the modern web needs, which is exactly the gap ACME (RFC 8555, the protocol behind Let's Encrypt) closes: a server proves it controls a domain by completing an automated challenge — serving a specific file over HTTP (HTTP-01), publishing a specific DNS record (DNS-01), or presenting a specific value during the TLS handshake itself (TLS-ALPN-01) — and once that challenge passes, a certificate is issued and can be renewed automatically before it ever expires, with no human involved.
ACME domain validation and issuance
- 1
Client requests a certificate
An ACME client (like Certbot or a built-in load-balancer integration) asks the CA for a certificate for a domain.
- 2
CA issues a challenge
The CA asks the client to prove control of the domain via HTTP-01, DNS-01, or TLS-ALPN-01.
- 3
Client completes the challenge
The client publishes the required file, DNS record, or TLS response.
- 4
CA verifies and issues
The CA checks the challenge, signs the certificate, and the client installs it — all without a human in the loop.
Shrinking lifetimes are forcing this automation industry-wide
The X.509 module's "shift to short-lived certificates" section covers why lifetimes keep shrinking; the operational consequence is that manual issuance is no longer a viable option at any scale. The CA/Browser Forum's maximum publicly-trusted certificate validity has already dropped from 398 days to 200 days as of March 2026, is scheduled to fall to 100 days in March 2027, and to just 47 days by March 2029 — figures set on a fixed public timeline, not a rough trend.
Let's Encrypt has run at 90-day certificates since it launched in 2015, specifically to force automation from day one: with ACME renewal running on a schedule (commonly renewing at roughly the two-thirds mark for safety margin), a domain renews on the order of six times a year, entirely invisibly to whoever operates it.
Practice
By the CA/Browser Forum's March 2029 target, the maximum certificate validity will be 47 days. Rounding up to the nearest whole renewal, how many times must a continuously-running domain renew its certificate to cover one 365-day year?