> Lesson 9 of PKI in 90 minutes: certificate inventory, the shrinking lifetime schedule, ACME automation, HSMs, key ceremonies and running a private CA. Source: https://pkizerotohero.com/course/running-pki/ · Last reviewed: 2026-10-20 # Running PKI About 10 minutesCrash course **In one sentence:** Many PKI outages are expired certificates nobody tracked; as lifetimes keep shrinking, an inventory, ACME automation and well-guarded CA keys are no longer optional. ## 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](https://pkizerotohero.com/handbook/glossary/#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 *Diagram: A loop of six steps: 1 inventory (where, owner, expiry), 2 request (new key and CSR), 3 validate (the CA checks the name), 4 issue (the CA signs), 5 deploy and reload (the server uses the new certificate), 6 monitor and renew before expiry, which leads back to step 2. In the middle: an ACME client automates steps 2 to 5.* The certificate lifecycle. An ACME client runs the middle of the loop on a schedule; people own the inventory and the monitoring. [ACME](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#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](https://pkizerotohero.com/handbook/glossary/#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. Why it matters to the business Ask your team Do we have a complete inventory with an owner for every certificate? What share of renewals is automated today, and what is our plan before lifetimes reach 47 days? ## Try it *Interactive tool: Lifetime calendar (runs in the browser at [/tools/lifetime/](https://pkizerotohero.com/tools/lifetime/))* 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](https://pkizerotohero.com/handbook/certificate-lifecycle/) - Handbook: [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/) - Handbook: [Guarding the keys: HSMs and key ceremonies](https://pkizerotohero.com/handbook/hsm-and-key-ceremonies/) - Handbook: [A CA of your own: private two-tier PKI](https://pkizerotohero.com/handbook/private-ca/) - Next lesson: [Beyond the browser, and what comes next](https://pkizerotohero.com/course/beyond-the-browser/) **Early edition.** Checked against the standards; an independent expert review is in progress. Found a mistake? [Tell us](https://pkizerotohero.com/contact/?topic=content-error&page=/course/running-pki/). Last reviewed 20 October 2026Edition 0.9 ## Go deeper in the handbook - [Chapter 19: Inventory, expiry and renewal](https://pkizerotohero.com/handbook/certificate-lifecycle/) - [Chapter 20: ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/) - [Chapter 21: Guarding the keys: HSMs and key ceremonies](https://pkizerotohero.com/handbook/hsm-and-key-ceremonies/) - [Chapter 22: A CA of your own: private two-tier PKI](https://pkizerotohero.com/handbook/private-ca/)