Running PKI

The situation

Monday, nine in the morning. The customer portal and the mobile app stop working at the same moment. Nobody changed anything. Two hours later someone finds the cause: a certificate expired over the weekend.

The colleague who renewed it by hand last year has left the company. Nobody else knew it existed.

What is going on

Expiry is the outage you can plan for

Certificates expire on purpose: expiry is the hard stop from lesson 8. Most expiry outages are bookkeeping failures, not technical ones. Nobody knew where the certificate was installed, or who owned it.

The cure is a certificate inventory: for every certificate, where it is installed, who owns it, who issued it, when it expires and how it is renewed. Certificate Transparency logs list your public certificates; network scans find what is actually served; your CA accounts list what was issued. Certificates from private CAs appear only in your own records.

Lifetimes are shrinking

Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime of a public TLS certificate fell from 398 days to 200 days on 15 March 2026. It falls to 100 days from 15 March 2027, and to 47 days from 15 March 2029. By then a CA may reuse a domain check for at most 10 days.

Shorter lifetimes shrink the window in which a leaked key or a wrongly issued certificate stays usable, and they force automation. Renewing by hand every few weeks is not realistic for anyone with more than a handful of certificates. Do not count on reminders either: Let's Encrypt no longer sends expiration reminder emails.

Robots that renew: ACME

Swipe sideways to see the whole diagram.

ACME (RFC 8555) is the protocol that lets software on your server get certificates without a person. The ACME client places an order for the names, proves control of them, sends a CSR, downloads the certificate, installs it and reloads the service, on a schedule, well before expiry. Many public CAs and private CA products support it.

The most common failure is the last step: the new certificate is on disk, but the service was never reloaded and still serves the old one.

Guarding the keys

High-value keys, above all CA keys, belong in a hardware security module (HSM): hardware that signs on request but never releases the key. Access control still matters, because anyone who can command the HSM can use the key. CA keys are created in a key ceremony: scripted, witnessed and recorded, with duties split so that no single person can act alone.

A CA of your own

For internal names, devices and client certificates, organisations run a private CA, usually in two tiers: an offline root, used only in ceremonies, signs an online issuing CA that does the daily work. A Certificate Policy says what must be true; a Certification Practice Statement says how the CA achieves it. Badly configured certificate templates are a classic weakness, so review who may request what.

Try it

Try it: Lifetime calendarOpen the full tool

Runs in your browser. Nothing you type or paste is sent anywhere.

Start from

How often you renewA certificateIts dates

You renew a certificateOnce a year (365 days)Every six months (183 days)Every three months (90 days)Every two months (60 days)Every month (30 days)Every … days

Certificates you look after

The schedule for public TLS certificates

Issued from	Longest lifetime	Domain check reuse	Renewals a year, at least
1 September 2020	398 days	398 days (from 1 October 2021)	1
15 March 2026	200 days	200 days	2
15 March 2027	100 days	100 days	4
15 March 2029	47 days	10 days	8

From the CA/Browser Forum Baseline Requirements (sections 6.3.2 and 4.2.1), checked 20 October 2026. Renewals a year: 365 divided by the lifetime, rounded up; renewing earlier means more.

See how often a certificate must be renewed at each step of the schedule. Count how many renewals a year your team would face with your current number of certificates.

Check

Check yourself

Why are the maximum lifetimes of public TLS certificates being shortened?

1. So that CAs can sell more certificates
2. To shrink the time a wrong or compromised certificate stays usable, and to push everyone to automate
3. Because long-lived certificates use weaker encryption

Show answer

Answer B To shrink the time a wrong or compromised certificate stays usable, and to push everyone to automate

What happened

Shorter lifetimes limit how long a bad certificate can be misused, and they make manual renewal impractical.

Why

Revocation is unreliable (lesson 8), so expiry is the dependable stop. Frequent renewal only works with automation, which also makes changing CAs or algorithms easier.

The rule

Plan for short lifetimes by automating renewal end to end, including the reload.

Check yourself

Your ACME client reports a successful renewal, but the website still serves the old certificate, which expires tomorrow. What is the most likely cause?

1. The CA revoked the new certificate
2. ACME only renews the private key, not the certificate
3. The service was not reloaded, so it still uses the certificate it loaded at startup

Show answer

Answer C The service was not reloaded, so it still uses the certificate it loaded at startup

What happened

Many servers read their certificate once at startup. Until they are reloaded, they keep serving the old one.

Why

The ACME client's job ends when the file is written, unless it is configured to reload or restart the service afterwards.

The rule

Automation is not finished until the running service serves the new certificate; monitor what is actually served.

Check yourself

In a private two-tier PKI, why is the root CA kept offline?

1. So it cannot be reached or misused over the network; it only signs issuing CA certificates and its CRLs at planned ceremonies
2. Because the law forbids online roots
3. To make certificate issuing faster

Show answer

Answer A So it cannot be reached or misused over the network; it only signs issuing CA certificates and its CRLs at planned ceremonies

What happened

The offline root is used rarely, under controlled conditions, to sign the issuing CAs and its own revocation lists.

Why

If the root key were compromised, every certificate below it would be untrustworthy. Keeping it offline removes the network as a path to it, while the online issuing CA does the daily work and can be replaced if needed.

The rule

Keep the root offline and use it only in ceremonies; let issuing CAs take the daily risk.

Takeaways

• Many PKI outages are expired certificates nobody tracked: keep an inventory with an owner for each one.
• Lifetimes are falling step by step to 47 days; automate renewal with ACME, including the reload.
• Guard CA keys in HSMs and ceremonies, and keep a private root offline.

Go further

• Handbook: Inventory, expiry and renewal
• Handbook: ACME and the 47-day schedule
• Handbook: Guarding the keys: HSMs and key ceremonies
• Handbook: A CA of your own: private two-tier PKI
• Next lesson: Beyond the browser, and what comes next

In the gameLevel 19: Expiry dayClocktower, Keystone. In development