> Find every certificate, monitor expiry with OpenSSL, renew and reload without outages, and get ready for much shorter TLS certificate lifetimes. Source: https://pkizerotohero.com/handbook/certificate-lifecycle/ · Last reviewed: 2026-10-20 Part VI: Running PKI · Chapter 19 # Inventory, expiry and renewal **In one sentence:** Every certificate expires and lifetimes keep shrinking, so you need an inventory, an owner for each certificate, monitoring of what servers really send, and automated renewal. ## Who is this for - [IT ops](https://pkizerotohero.com/start/#itops) - [Developer](https://pkizerotohero.com/start/#developer) - [Leader](https://pkizerotohero.com/start/#leader) - [Expert](https://pkizerotohero.com/start/#expert) - [Beginner](https://pkizerotohero.com/start/#beginner) Level: **Practitioner** - [New to this? Start with The idea](https://pkizerotohero.com/handbook/certificate-lifecycle/#the-idea) - [Developer? Jump to How it really works](https://pkizerotohero.com/handbook/certificate-lifecycle/#how-it-really-works) - [IT ops? At work](https://pkizerotohero.com/handbook/certificate-lifecycle/#at-work) - [Leader? Why it matters](https://pkizerotohero.com/handbook/certificate-lifecycle/#why-it-matters-to-the-business) ## The idea - Beginner Every certificate has an end date. After that moment, every client refuses it. A website shows a full-page warning, an API call fails, a phone app stops syncing, and a payment terminal stops talking to its bank. Nothing was attacked. A date simply passed. Expiry is deliberate. A certificate that ends soon limits how long a stolen key or a wrongly issued certificate stays useful, because taking certificates back early does not work reliably (see [Revocation](https://pkizerotohero.com/handbook/revocation/)). That is why the rules for publicly trusted certificates are making lifetimes much shorter: - before 15 March 2026: at most 398 days; - from 15 March 2026: at most 200 days; - from 15 March 2027: at most 100 days; - from 15 March 2029: at most 47 days. At the shortest limit, each name needs a new certificate at least eight times a year. A spreadsheet and a calendar reminder cannot keep up with that. The work around a certificate is called the [certificate lifecycle](https://pkizerotohero.com/handbook/glossary/#certificate-lifecycle). You request a certificate, the CA issues it, you deploy it, the service reloads it, you monitor it, and you renew it in time. At the end, you retire it, or revoke it if its key was exposed. Three things decide whether this runs smoothly: 1. A [certificate inventory](https://pkizerotohero.com/handbook/glossary/#certificate-inventory): a list of every certificate, where it is installed and when it expires. 2. An **owner** for every certificate: a team that is responsible for renewing it and answers the alarm. 3. **Automation**, so that renewal and reload happen without a person. The next chapter, [ACME and the 47-day schedule](https://pkizerotohero.com/handbook/acme/), shows how. In the game The Clocktower In the game, every certificate in Keystone is a candle in the Clocktower, and the clockkeeper’s ledger lists each candle and how long it burns. Ken’s job is to light a new candle before the old one goes out. Where it stops being true: real certificates give no warning as they burn down, many of them hide in places no ledger lists until you go and look, and a freshly lit candle does nothing until the service reloads it. ## How it really works - Developer - Expert ### What does “valid” mean inside a certificate? Every certificate carries two times in its validity field: `notBefore` and `notAfter`. The X.509 profile, RFC 5280, defines the validity period as “the time interval during which the CA warrants that it will maintain information about the status of the certificate” ([section 4.1.2.5](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.5)). A client compares both times with its own clock. That is why a device with a wrong clock rejects perfectly good certificates (see [Anatomy of an X.509 certificate](https://pkizerotohero.com/handbook/x509-certificates/)). ### What is the lifecycle of a certificate? *Diagram: A loop of six steps around a central inventory box that lists every certificate, its owner and its location. 1 Request: new key and CSR. 2 Issue: the CA validates and signs. 3 Deploy: everywhere it is used. 4 Reload: the service picks it up. 5 Monitor: the live endpoint and the days left. 6 Renew: well before expiry, which leads back to step 1. Off the loop: revoke after a key compromise, and retire the certificate when the service goes away.* The certificate lifecycle. Every step needs to know where the certificate lives. Each step can fail on its own. A renewal can succeed while the deployment fails. A deployment can succeed while the service keeps serving the old certificate from memory. Monitoring that only checks files on disk sees none of this. The rule is simple: **monitor what clients actually receive.** ### Why are lifetimes getting shorter? CA/Browser Forum Ballot SC-081v3, adopted on 11 April 2025, changed two sections of the [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/). Section 6.3.2 sets the maximum certificate lifetime above. Section 4.2.1 sets how long a CA may reuse an earlier check that you control a domain. That reuse period shrinks too, to 10 days from 15 March 2029, so the CA will re-check control of your names almost every time it issues. *Diagram: Four bars whose length shows the maximum lifetime. Issued before 15 March 2026: 398 days, at least 1 certificate a year. Issued from 15 March 2026: 200 days, at least 2 a year. Issued from 15 March 2027: 100 days, at least 4 a year. Issued from 15 March 2029: 47 days, at least 8 a year. Source: CA/Browser Forum ballot SC-081v3.* The maximum lifetime of publicly trusted TLS certificates, step by step. There are three reasons behind the schedule: - **Revocation is weak.** Let’s Encrypt put it plainly when it made six-day certificates generally available: “revocation is an unreliable system” ([Let’s Encrypt](https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability)). A short lifetime is the limit that every client enforces. - **Fresher checks.** Domain control and the details in a certificate are re-validated more often, so a name that changed hands stops being covered sooner. - **Agility.** An organisation that renews automatically every few weeks can also change CA after a [distrust](https://pkizerotohero.com/handbook/famous-failures/), or change algorithm when [post-quantum](https://pkizerotohero.com/handbook/post-quantum/) certificates arrive, without a project. These limits apply to publicly trusted TLS certificates. Certificates from your own [private CA](https://pkizerotohero.com/handbook/private-ca/) follow your own policy, but they expire just the same, and they usually cause the outages nobody saw coming. ### Where do certificates hide? Public websites are the easy part. The outages come from the places nobody listed: - **Load balancers, reverse proxies and CDNs**, which often hold their own copy of the certificate. - **Kubernetes secrets** of type `kubernetes.io/tls`, used by ingress controllers and service meshes. - **Java keystores** (`.jks` or `.p12` files) inside application servers, message brokers and build tools. - **Windows certificate stores** on IIS servers, domain controllers, RDP hosts and ADFS servers. - **Appliances:** firewalls, VPN gateways, traffic-inspection devices, storage arrays, printers and server management controllers. - **Clients:** mutual-TLS client certificates (see [mutual TLS](https://pkizerotohero.com/handbook/mutual-tls/)), and private CA roots built into applications. - **Internal names** that no public monitor will ever see, because their certificates come from a private CA. ### Why does a renewal fail even when the job “worked”? - **The service was never reloaded.** Many servers read the certificate only at start-up. The new file sits on disk while the old certificate expires in memory. - **Only one node was updated.** One server in a cluster, or one region, still serves the old certificate. - **The chain is incomplete.** The new certificate went out without its intermediate, and non-browser clients fail (see [Certificate chains](https://pkizerotohero.com/handbook/certificate-chains/)). - **Validation failed silently.** A DNS change, a firewall rule or a new CDN broke the domain check, and the renewal job’s errors went to a log nobody reads. - **The warning never came.** Let's Encrypt no longer sends expiration reminder emails (since 4 June 2025). Your own monitoring must take its place. ## At work - Developer - IT ops ### How do I check a certificate file? ```bash openssl x509 -in cert.pem -noout -enddate ``` ```text notAfter=Dec 3 14:34:31 2026 GMT ``` For scripts, `-checkend` takes a number of seconds and answers with an exit code: 0 if the certificate is still valid at that point, 1 if it will have expired. Here the same certificate is checked 30 days ahead, then 60 days ahead: ```bash openssl x509 -in cert.pem -noout -checkend 2592000; echo "exit=$?" openssl x509 -in cert.pem -noout -checkend 5184000; echo "exit=$?" ``` ```text Certificate will not expire exit=0 Certificate will expire exit=1 ``` ### How do I check what a server really sends? Ask the live endpoint, because that is what clients see: ```bash openssl s_client -connect www.digicert.com:443 -servername www.digicert.com /dev/null \ | openssl x509 -noout -startdate -enddate ``` ```text notBefore=Oct 11 00:00:00 2026 GMT notAfter=Nov 26 23:59:59 2026 GMT ``` That certificate already lives no longer than the final limit of 47 days. The same check in a loop gives the days left for a list of hosts: ```bash #!/usr/bin/env bash # Print the days left on the certificate each host serves. for host in "$@"; do end=$(echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \ | openssl x509 -noout -enddate | cut -d= -f2) days=$(( ($(date -d "$end" +%s) - $(date +%s)) / 86400 )) echo "$host $days days ($end)" done ``` Saved as `days-left.sh` and run with `bash days-left.sh www.digicert.com letsencrypt.org www.wikipedia.org`: ```text www.digicert.com 38 days (Nov 26 23:59:59 2026 GMT) letsencrypt.org 44 days (Dec 3 14:34:31 2026 GMT) www.wikipedia.org 74 days (Jan 2 18:34:50 2027 GMT) ``` This uses GNU `date`, as on Linux and in Git Bash. Use `-servername` every time: without it, a server that hosts many names may send its default certificate instead of the one you meant to check. ### How do I look inside Kubernetes, Java and Windows? These commands only read certificates. Kubernetes stores TLS certificates in secrets of type `kubernetes.io/tls`: ```bash kubectl get secrets -A --field-selector type=kubernetes.io/tls kubectl get secret my-tls -n my-app -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -subject -enddate ``` Java keystores, with the `keytool` that ships with the JDK: ```bash keytool -list -v -keystore keystore.p12 | grep -E "Alias name|until:" ``` Windows certificate stores, in PowerShell: ```powershell Get-ChildItem Cert:\LocalMachine\My | Where-Object NotAfter -lt (Get-Date).AddDays(30) | Select-Object Subject, NotAfter, Thumbprint ``` ### How do I renew without an outage? 1. **Renew early.** Let’s Encrypt’s [integration guide](https://letsencrypt.org/docs/integration-guide/) recommends renewing “when they have a third of their total lifetime left”. That leaves time to fix a failed renewal before anyone notices. 2. **Use a new key** each time, unless something forces you to keep the old one, such as a pinned key. 3. **Deploy the full chain**: the certificate plus its intermediate. 4. **Reload, then verify.** For nginx, test the configuration first, then reload without dropping connections: ```bash sudo nginx -t && sudo systemctl reload nginx ``` Many Java applications read their keystore only at start-up and need a restart. Appliances usually need an upload through their API or web interface. 5. **Check the live endpoint again** and compare the serial number and end date with the new certificate: ```bash openssl s_client -connect www.example.com:443 -servername www.example.com /dev/null \ | openssl x509 -noout -serial -enddate ``` ### What belongs in the inventory? | Field | Why you need it | | --- | --- | | Names (SANs) | To match the certificate to services and to CT search results | | Where it is deployed | Every server, load balancer, secret or appliance that holds a copy | | Owner | The team that renews it and answers the alarm | | Issuer (CA) | To act quickly if that CA is distrusted | | Expiry date | For monitoring and planning | | Renewal method | Automated (which tool) or manual (which procedure) | | Key location | File, keystore, HSM or cloud key service | Fill it from several sources: scans of TLS ports on your networks, [Certificate Transparency](https://pkizerotohero.com/handbook/certificate-transparency/) searches for your public names, exports from your CA accounts, cloud certificate services, configuration management and Kubernetes clusters. Then keep it current automatically. A list that people update by hand is out of date within weeks. ### When should monitoring alert? Alert on a share of the lifetime, not a fixed number of days. A rule like “alert 30 days before expiry” fires soon after issue for a certificate that lives 47 days, and people learn to ignore it. If renewal is meant to happen with a third of the lifetime left, alert when a certificate is well past that point and still not replaced, for example with a sixth of its lifetime left. Send alerts to the owning team, not to a shared mailbox. The lifetime calendar shows how often each certificate must be renewed under each step of the schedule: *Interactive tool: Lifetime calendar (runs in the browser at [/tools/lifetime/](https://pkizerotohero.com/tools/lifetime/))* When something does expire, the decoder shows it plainly, and the error pages explain the client messages: [certificate has expired](https://pkizerotohero.com/errors/openssl-certificate-has-expired/) in OpenSSL and [NET::ERR\_CERT\_DATE\_INVALID](https://pkizerotohero.com/errors/chrome-err-cert-date-invalid/) in Chrome. *Interactive tool: Certificate decoder (runs in the browser at [/tools/decoder/](https://pkizerotohero.com/tools/decoder/))* ## Common mistakes - **“Renewal is a yearly calendar job.”** Under the new schedule it happens several times a year for every name. It must be automated. - **“Someone knows where all our certificates are.”** Usually nobody does. Build the inventory from scans and logs, not from memory. - **“The renewal succeeded, so we are done.”** Not until every copy is deployed, every service has reloaded and the live endpoint shows the new certificate. - **“The CA will remind us.”** Let’s Encrypt has stopped sending expiry emails, and a reminder to a former colleague’s mailbox helps nobody. - **“Internal certificates are less important.”** Internal certificates protect APIs, databases and security devices. When one expires, the impact can be just as large. ## Why it matters to the business - Leader Why it matters to the business Short lifetimes need automation, not more reminders From 15 March 2029, every public certificate you run must be replaced at least eight times a year. Each manual renewal costs skilled time and carries a chance of an outage, so the risk grows with every certificate you add. The decisions are: fund an inventory and automated renewal now, while lifetimes are still longer; give every certificate an owning team; and measure renewals that happen without a person. The end state is boring: certificates renew themselves, and people only hear about the rare one that fails. ## Check yourself Check yourself Your monitoring alerts 30 days before a certificate expires. What goes wrong once certificates only last a few weeks? 1. Nothing, 30 days is still a good margin 2. It alerts soon after every issue, so alerts get ignored 3. Short-lived certificates cannot be monitored Show answer Answer B It alerts soon after every issue, so alerts get ignored What happened A certificate that lives only a few weeks drops below 30 days left soon after it is issued. Why Fixed thresholds do not scale with shorter lifetimes, and constant alerts train people to ignore them. The rule Alert on a share of the lifetime, and only when renewal is overdue. Check yourself The renewal job succeeded last night, but clients still receive the old certificate. What is the most likely cause? 1. The CA revoked the new certificate 2. The service never reloaded the new certificate 3. The clients cache certificates for a week Show answer Answer B The service never reloaded the new certificate What happened The new certificate is on disk, but the server still serves the one it loaded at start-up. Why Many services read certificates only when they start or reload. The rule Renew, deploy, reload, then verify the live endpoint. Check yourself Where are you most likely to miss a certificate during an inventory? 1. The main public website 2. An appliance, a Java keystore or a Kubernetes secret nobody listed 3. The CA's root certificate in the browser Show answer Answer B An appliance, a Java keystore or a Kubernetes secret nobody listed What happened Certificates in appliances, keystores and clusters are often installed once and forgotten. Why Public websites are watched by many people. Internal systems are watched by nobody unless you add them. The rule Discover certificates from scans, logs and platforms, and keep the inventory current automatically. ## Go deeper - [CA/Browser Forum Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/): the decision behind the step-by-step lifetime schedule. - [Baseline Requirements](https://cabforum.org/working-groups/server/baseline-requirements/requirements/), sections 4.2.1 and 6.3.2: the current limits for lifetime and validation reuse. - [RFC 5280 section 4.1.2.5](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.5): what the validity period means. - [NIST SP 1800-16](https://csrc.nist.gov/pubs/sp/1800/16/final): NIST’s practice guide to TLS server certificate management, including inventory and ownership. - [Let’s Encrypt integration guide](https://letsencrypt.org/docs/integration-guide/): when and how to renew automatically. - [Let’s Encrypt: ending expiration emails](https://letsencrypt.org/2025/01/22/ending-expiration-emails/): why you need your own monitoring. The crash course covers the lifecycle in [lesson 9, Running PKI](https://pkizerotohero.com/course/running-pki/). **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=/handbook/certificate-lifecycle/). Last reviewed 20 October 2026Edition 0.9 ## Keep going Crash course: [Lesson 9: Running PKI](https://pkizerotohero.com/course/running-pki/) ### Error pages for this chapter - [verify error:num=10:certificate has expired](https://pkizerotohero.com/errors/openssl-certificate-has-expired/) - [NET::ERR\_CERT\_DATE\_INVALID](https://pkizerotohero.com/errors/chrome-err-cert-date-invalid/) ### How-to guides - [How to check when a certificate expires, and monitor it](https://pkizerotohero.com/guides/check-certificate-expiry/) - [How to install a certificate in IIS](https://pkizerotohero.com/guides/install-certificate-iis/) - [How to get and renew Let's Encrypt certificates with certbot](https://pkizerotohero.com/guides/certbot-lets-encrypt/) - [How to automate certificates in Kubernetes with cert-manager](https://pkizerotohero.com/guides/kubernetes-cert-manager/) - [How to automate certificates on Windows with win-acme](https://pkizerotohero.com/guides/win-acme-windows/) - [How to run a small private CA with step-ca (lab)](https://pkizerotohero.com/guides/private-ca-step-ca/) - [How to prepare for short-lived certificates: a checklist](https://pkizerotohero.com/guides/prepare-47-day-certificates/) ### Tools - [Lifetime calendar](https://pkizerotohero.com/tools/lifetime/): See how long a certificate may live on any date, and when to renew. - [Certificate decoder](https://pkizerotohero.com/tools/decoder/): Paste a PEM certificate and read every field in plain words. ### Topics - [Lifecycle and automation](https://pkizerotohero.com/topics/lifecycle-and-automation/)