TLS certificate lifetimes are shrinking to 47 days: the CA/Browser Forum schedule and what to automate

The maximum lifetime of a publicly trusted TLS certificate is getting much shorter. Under CA/Browser Forum ballot SC-081v3, adopted in April 2025, the limit falls from 398 days to 47 days in three steps between March 2026 and March 2029. The first step is already in force: certificates issued since 15 March 2026 can be valid for at most 200 days.

If your certificates renew automatically, little changes. If anyone in your team still renews certificates by hand, now is the time to plan for doing it eight or more times a year, or to stop doing it by hand.

The schedule

The dates below come from section 6.3.2 of the CA/Browser Forum Baseline Requirements (the TLS BRs, version 2.3.1 at the time of writing), which every public certificate authority (CA) trusted by the major browsers must follow.

Two details matter in practice. First, the BRs say CAs SHOULD NOT issue for the full permitted period, so expect lifetimes a day or so under each cap. Second, the "reuse" column is how long a CA may rely on an earlier proof that you control a domain. From March 2029 that proof can be at most 10 days old, which means domain validation effectively happens at every renewal. For organisation details in OV and EV certificates, the reuse period dropped from 825 to 398 days on 15 March 2026.

Who decided this, and what it covers

The ballot passed in the Forum's Server Certificate Working Group with 25 certificate issuers voting yes, none voting no and five abstaining, and all four certificate consumers (Apple, Google, Microsoft and Mozilla) voting yes, as recorded on the ballot page.

The rules apply to publicly trusted TLS server certificates, the kind browsers accept for websites and APIs on the internet. Certificates from a private, internal CA that you run yourself are outside the scope of the BRs, although shorter lifetimes are good practice there too.

The ballot's reasoning is straightforward: a certificate describes facts at one moment, and the longer it lives, the more likely those facts (domain ownership, key control) have changed. Revocation through CRLs and OCSP has proven unreliable at internet scale, so short lifetimes limit the damage from a mis-issued or compromised certificate regardless of revocation, and make it easier to move to new algorithms when needed.

Related rules that can break issuance

• DNSSEC validation by CAs (since 15 March 2026). CAs must validate DNSSEC when checking domain control and CAA records, and a validation failure such as SERVFAIL must not be treated as permission to issue. A domain with broken DNSSEC can no longer get or renew certificates.
• CAA parameters (from 15 March 2027). CAs must process the accounturi and validationmethods CAA parameters defined in RFC 8657, so records that use them will be enforced everywhere.
• Email-based domain validation (ends 15 March 2028). Methods that prove control by sending an email to an address such as admin@ or to a contact published in DNS may no longer be used. If your certificate vendor validates you by email today, ask what replaces it.

What it means for your servers

Count the renewals. A 47-day certificate means roughly eight renewals a year per certificate, and with the recommended practice of renewing at about two thirds of the lifetime, closer to twelve. Any process that needs a person to generate a CSR, paste a certificate into a panel or copy files to a server will not keep up.

The places that usually break are not the main website, which often already uses ACME automation, but the forgotten ones: a load balancer, a mail server, a VPN appliance, a printer or NAS admin page, or an internal tool that someone set up with a one-year certificate.

Find out what you have

Check the issuer and expiry date of any public endpoint:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -enddate

To get a simple warning when a certificate expires within 14 days (1,209,600 seconds), use -checkend:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 1209600 && echo "OK" || echo "Expires within 14 days"

Run it for every hostname you own, including mail (port 465 or 993) and any non-web service, and keep the list in a monitoring tool rather than a spreadsheet.

Automate issuance and renewal

The standard way to automate is the ACME protocol (RFC 8555), supported by Let's Encrypt and by many commercial CAs. On Debian and Ubuntu, Certbot from the distribution packages installs a systemd timer that runs renewals twice a day. Confirm it is active and that renewal works end to end:

systemctl list-timers certbot.timer
sudo certbot certificates
sudo certbot renew --dry-run

Renewal is only half the job: the new certificate must also be loaded. Make sure a deploy hook reloads the service that uses it, for example --deploy-hook "systemctl reload nginx". Avoid scripts that renew on a fixed number of days (for example every 60 or 80 days); renew at about two thirds of the lifetime, or use a client that supports ACME Renewal Information (ARI), which lets the CA tell the client when to renew.

Things to avoid

• Pinning a specific certificate or intermediate in apps or devices. With frequent renewals, pinned values go stale quickly.
• Relying on the CA to email you before expiry. Use your own monitoring.
• Buying a multi-year certificate expecting to install it once. Each issued certificate is still capped; ask your vendor how reissuance works.

What you should do

• List every certificate you depend on, with its issuer, expiry date and how it is renewed.
• Move manual renewals to ACME automation now, while the cap is 200 days and mistakes are cheap.
• Test renewals with certbot renew --dry-run (or your client's equivalent) and make sure the service reloads afterwards.
• Add expiry monitoring with alerts at least 14 days ahead.
• If you use DNSSEC, confirm it validates correctly; if your vendor validates domains by email, ask what replaces it before March 2028.

On Skyline Cloud web hosting plans, SSL certificates are issued and renewed automatically; on a self-managed VPS, setting up and monitoring renewal is part of running the server.

Sources

• cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data...
• cabforum.org/working-groups/server/baseline-requirements/documents
• github.com/cabforum/servercert/blob/main/docs/BR.md
• letsencrypt.org/2025/12/02/from-90-to-45
• manpages.debian.org/trixie/openssl/openssl-x509.1ssl.en.html
• packages.debian.org/trixie/all/certbot/filelist
• cloud.alskyline.com/hosting