Inventory, expiry and renewal

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). 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. 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: 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, shows how.

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). 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).

What is the lifecycle of a certificate?

Swipe sideways to see the whole diagram.

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. 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.

Swipe sideways to see the whole diagram.

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). 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, or change algorithm when post-quantum certificates arrive, without a project.

These limits apply to publicly trusted TLS certificates. Certificates from your own 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), 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).
• 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.

How do I check a certificate file?

openssl x509 -in cert.pem -noout -enddate

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:

openssl x509 -in cert.pem -noout -checkend 2592000; echo "exit=$?"
openssl x509 -in cert.pem -noout -checkend 5184000; echo "exit=$?"

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:

openssl s_client -connect www.digicert.com:443 -servername www.digicert.com </dev/null 2>/dev/null \
  | openssl x509 -noout -startdate -enddate

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:

#!/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:

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:

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:

keytool -list -v -keystore keystore.p12 | grep -E "Alias name|until:"

Windows certificate stores, in 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 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:

   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:

   openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
     | openssl x509 -noout -serial -enddate

What belongs in the inventory?

Fill it from several sources: scans of TLS ports on your networks, 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:

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.

When something does expire, the decoder shows it plainly, and the error pages explain the client messages: certificate has expired in OpenSSL and NET::ERR_CERT_DATE_INVALID in Chrome.

Try it: Certificate decoderOpen the full tool

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

Paste a certificate

Try a sampleChoose a sample…A website certificate (www.example.com)An expired certificateA wildcard certificate (*.example.com)A certificate with a Common Name but no SANA self-signed root CAA complete chain: leaf, intermediate and root

-----BEGIN CERTIFICATE----- MIIC1jCCAnygAwIBAgIQNPchftz8jn6EE0nYthv4IzAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI1MTEwMTAwMDAwMFoXDTI2 MDEzMDAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEnFxMTbSS6N//zfTxXpHxlwQXb/vUy+GJ0VD/hV2T qh4hwe8YIotO6LTc8gcoN7U/lzWAxB0YGCQNdl3ZkaeNC6OCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FLePvyuDFGAE/tNEqDYHGxSlxoD9MB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSAAwRQIhAM8HGMZHERBn faVlrjwlVBfFzLIBiMhxHlwupcIdsXYfAiBjweZeZ9ch63PQ3YYp81rY4QHX1y9Q vdp9yJS+yypzgg== -----END CERTIFICATE-----

PEM text, several PEM blocks, or a .pem, .crt, .cer or .der file (drop it on the box). Certificates are public, so they are safe to paste.

DecodeClearChoose a file

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.

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: the decision behind the step-by-step lifetime schedule.
• Baseline Requirements, sections 4.2.1 and 6.3.2: the current limits for lifetime and validation reuse.
• RFC 5280 section 4.1.2.5: what the validity period means.
• NIST SP 1800-16: NIST’s practice guide to TLS server certificate management, including inventory and ownership.
• Let’s Encrypt integration guide: when and how to renew automatically.
• Let’s Encrypt: ending expiration emails: why you need your own monitoring.

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

The crash course covers the lifecycle in lesson 9, Running PKI.