How to prepare for short-lived certificates: a checklist

Before you start

• A named owner for the whole programme, and a sponsor who can approve tools and staff time.
• Read access to your public CA accounts, DNS, cloud consoles and Kubernetes clusters.
• An hour for the first inventory pass, and this page as the checklist.

Why this matters: CA/Browser Forum Ballot SC-081v3 shortens the life of every publicly trusted TLS certificate in steps:

By the last step, each name needs a new certificate at least eight times a year, and the CA re-checks your control of the name almost every time. Anything renewed by hand will eventually expire. The lifetime calendar shows the maximum for any issue date:

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.

Steps

1. Build the inventory

You cannot automate what you have not found. Combine several sources, because each one misses something:

• Certificate Transparency searches for every public name you own.
• Exports from every CA account, including ones that individual teams opened.
• Cloud certificate services, CDNs and load balancers.
• Kubernetes TLS secrets: kubectl get secrets -A --field-selector type=kubernetes.io/tls.
• Java keystores, Windows certificate stores and appliances (firewalls, VPN gateways, storage, management controllers).
• A scan of what servers really send. This small script, for Linux, WSL or Git Bash, shows each certificate’s lifetime and how much of it has passed:

#!/bin/sh
# cert-age.sh: for each host, show the certificate's lifetime and how much of it has passed.
now=$(date -u +%s)
for host in "$@"; do
  cert=$(openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null)
  start=$(printf '%s\n' "$cert" | openssl x509 -noout -startdate | cut -d= -f2)
  end=$(printf '%s\n' "$cert" | openssl x509 -noout -enddate | cut -d= -f2)
  issuer=$(printf '%s\n' "$cert" | openssl x509 -noout -issuer -nameopt multiline | awk -F' = ' '/commonName/{print $2}')
  s=$(date -u -d "$start" +%s); e=$(date -u -d "$end" +%s)
  life=$(( (e - s) / 86400 )); left=$(( (e - now) / 86400 )); used=$(( 100 * (now - s) / (e - s) ))
  printf '%-20s %3d-day certificate, %3d days left, %3d%% used, issuer %s\n' "$host" "$life" "$left" "$used" "$issuer"
done

$ sh cert-age.sh letsencrypt.org www.digicert.com github.com www.rfc-editor.org
letsencrypt.org       89-day certificate,  44 days left,  50% used, issuer YE2
www.digicert.com      46-day certificate,  37 days left,  19% used, issuer DigiCert EV RSA CA G2
github.com            89-day certificate,  40 days left,  54% used, issuer Sectigo Public Server Authentication CA DV E36
www.rfc-editor.org    90-day certificate,  80 days left,  10% used, issuer WE1

(Run on 20 October 2026. Days are rounded down, so a 90-day certificate that ends one second early shows as 89.) Some organisations already run on lifetimes shorter than the final limit. The script uses GNU date; on macOS, install GNU coreutils and use gdate, or adapt the two date conversions.

2. Give every certificate an owner and a renewal method

For each entry, record at least: the names, where it is deployed, the owning team, the CA, the expiry date, how it renews, and where the key lives. The lifecycle chapter explains each field. An entry without an owner is a future outage without anyone to call.

3. Sort everything into four groups

Certificates from your own private CA do not fall under these public rules. Decide their lifetimes in your own policy, and automate them anyway.

4. Automate with ACME

Choose one client per platform and use it everywhere: certbot on Linux, cert-manager in Kubernetes, win-acme on Windows, or your load balancer’s built-in ACME support. The guides for certbot, cert-manager, win-acme and wildcards with DNS-01 show the set-up.

Because domain validation may soon be reused for only 10 days, the challenge path must work on every renewal: port 80 for HTTP-01, a scoped DNS API token for DNS-01. Commercial CAs also offer ACME, often with an account binding key, so an OV contract does not have to mean manual renewal.

5. Turn on ARI

ACME Renewal Information lets the CA tell your client when to renew, for example earlier than planned before a mass revocation. It is RFC 9773, on the IETF standards track. Use a client that supports it (the ACME chapter lists them), and let it check at least twice a day. Without ARI, renew when about a third of the lifetime is left.

6. Make every renewal reach the service

A new file on disk is not a new certificate in production. For each deployment, confirm:

• the service reloads after renewal (a deploy hook, --exec, or a controller that watches the secret);
• the full chain is deployed, not just the leaf;
• every node, region and load balancer gets the new certificate.

Test with a forced renewal against the CA’s staging environment, then check the live serial number and end date.

7. Monitor independently of the renewal tooling

• Alert on the share of lifetime used, not a fixed number of days. A “30 days before expiry” rule fires at once for short certificates, and people learn to ignore it. With renewal planned at two-thirds, alert at around 80 to 85 percent used.
• Probe from outside, as the script above does, so a service that never reloaded is caught.
• Watch CT logs for certificates you did not expect.
• Do not rely on CA emails. Let's Encrypt no longer sends expiration reminder emails (since 4 June 2025).

8. Move client certificates to a private CA

Public TLS certificates are becoming server-only: Let's Encrypt certificates no longer include the TLS client authentication purpose (from 11 February 2026 for the default profile, and 8 July 2026 for the last opt-in profile), and from 15 March 2027, TLS certificates that chain to the Chrome Root Store must list only the TLS server authentication purpose. If any system logs in with a public certificate, move it to a private client CA, as in How to set up mutual TLS.

9. Budget for it

• Licences: check whether your CA contract charges per certificate or per year of coverage. Many CAs sell subscriptions that include unlimited reissues.
• Tools: a certificate management platform, or staff time to run open-source clients and monitoring.
• Replacements: appliances that cannot automate.
• People: a few days per platform to automate, then much less work than manual renewals.

10. Put dates on the plan, and rehearse

Work backwards from 15 March 2027, when the maximum falls to 100 days. Manual renewal at that rate is already painful, so aim to have everything critical automated before then, and everything before 15 March 2029.

Rehearse early with short certificates where your CA offers them. Let’s Encrypt, for example, offers 45-day certificates in its opt-in tlsserver profile (from 13 May 2026) and six-day certificates (from 15 January 2026). Its default lifetime falls to 64 days from 10 February 2027 and to 45 days from 16 February 2028, so ACME users meet short lifetimes on their CA’s schedule too.

Check it worked

• The inventory shows an owner and an automated renewal method for every public certificate.
• Running cert-age.sh across all your names shows no certificate past its alert threshold.
• A distrust drill passes: pick one CA and show how fast you could replace every certificate it issued. With full automation, that is a configuration change and one renewal cycle.

If something goes wrong

• A certificate expired although the renewal job reported success: the service was not reloaded, or another node still serves the old certificate. Clients report it as certificate has expired or NET::ERR_CERT_DATE_INVALID.
• Renewals fail with validation errors: a firewall, DNS change or expired DNS API token broke the challenge. Monitor the renewal job’s own failures, not just expiry.
• Too many alerts: thresholds are in fixed days. Switch to a share of the lifetime.
• Rate limits: a broken client retried in a loop. Fix it against the staging environment; ARI-coordinated renewals avoid most limits.
• An appliance cannot import certificates automatically: terminate TLS in front of it, or script its API, and set its replacement date.

Why this works

Short lifetimes limit the damage of a stolen key or a mistaken certificate without relying on revocation, and frequent renewal keeps organisations able to change CA or algorithm quickly (inventory, expiry and renewal). ACME and ARI make renewal a background task, and CT gives an independent record of what was issued (ACME and the 47-day schedule, Certificate Transparency). Once renewal is automatic, the shrinking schedule costs almost nothing.

Go deeper

• CA/Browser Forum Ballot SC-081v3: the schedule and the reasoning behind it.
• CA/Browser Forum Baseline Requirements, sections 4.2.1 and 6.3.2: the reuse periods and lifetimes in force.
• RFC 9773: ACME Renewal Information.
• Let’s Encrypt: integration guide: when and how a client should renew.
• Let’s Encrypt: from 90 to 45 days: one CA’s own timetable.