How to prepare for 199-day SSL certificates
From 24 February 2026 publicly trusted TLS certificates will be issued with a maximum validity of about 199 days, and the ceiling will keep dropping in the years that follow. This guide explains what the CA/Browser Forum decision changes in practice, what happens to multi-year certificate purchases, and how to prepare whether you manage 1, 10 or 100 certificates. It is written for admins and developers who actually own the renewal work.
What changes on 24 February 2026
The CA/Browser Forum is the industry body where certificate authorities and browser vendors agree on the rules for public TLS. It has voted to cut the maximum lifetime of public certificates in stages. The first stage lands on 24 February 2026: from that date no publicly trusted certificate may be issued with a validity longer than roughly 199 days, about 6.5 months. The agreed schedule then continues downward, to around 100 days in 2027 and about 47 days by 2029. Domain validation reuse periods shrink on the same schedule, so cached validations expire faster as well.
This is not optional and not vendor specific. Browsers enforce the limits in their root programs, so every CA, free or commercial, has to comply. A certificate issued after the deadline with a longer validity is simply rejected by clients.
Multi-year purchases survive, the certificate file does not
Commercially, nothing disappears. You can still buy a certificate for one, two or three years, and for OV and wildcard products the longer terms usually stay cheaper per year. What changes is the mechanics. The order becomes a subscription, and the file installed on your server is one short-lived issuance inside that subscription, valid at most 199 days. Mid-term you request a reissue, the CA signs a fresh certificate against the same order at no extra cost, and you deploy it. The private key may stay the same, but rotating it at each reissue is the better habit.
The practical consequence: install and forget for a year stops existing in February 2026. Every certificate you own becomes a recurring task with a hard deadline at least twice a year, and more often as the limits tighten.
Why manual reissue stops scaling
With one certificate the manual workflow is tolerable: generate a CSR, pass validation, download the file, install it, reload the web server. At 199 days that happens two or three times a year instead of once. With 10 certificates you are looking at 20 to 30 manual reissues a year, each one a chance to paste the wrong file, forget an intermediate, or miss a server in a cluster. With 100 certificates and the 2029 limit of 47 days you are handling roughly 800 reissues a year, which is about 3 per working day. No team does that reliably by hand.
Expired certificates are already among the most common self-inflicted outages, and every shortening step multiplies the number of deadlines. Treat February 2026 as the point where manual certificate handling turns from a routine chore into an operational risk.
Automation becomes the default
The sane response is to make issuance and renewal a machine's job. Two realistic paths:
- ACME: the protocol behind Let's Encrypt, also offered by several commercial CAs for DV and even OV products. Clients like certbot or acme.sh renew certificates well before expiry and reload your services.
- Provider tooling: if you buy certificates through a hosting or SSL provider, use its reissue API or managed installation instead of manual downloads.
A minimal ACME setup on a Debian or Ubuntu web server:
apt install certbot python3-certbot-nginx certbot --nginx -d example.com -d www.example.com # confirm the renewal timer is active and renewal actually works systemctl list-timers | grep certbot certbot renew --dry-run
For wildcard certificates use the DNS-01 challenge, ideally with the _acme-challenge record delegated by CNAME to a zone your automation is allowed to write to. Keep monitoring independent from the renewal tool: a cron job or external check that alerts when any certificate has less than 14 days left catches the failures the tool itself does not report.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -enddate
Preparation checklist by fleet size
1 certificate
- Note the current expiry date and set reminders 30 and 14 days before it.
- If DV is enough for you, move to ACME now and stop thinking about renewals at all.
- If you hold a paid OV or wildcard certificate, do one test reissue through your provider's panel today, so the first mandatory mid-term reissue is not a surprise.
About 10 certificates
- Build an inventory: domain, expiry date, where the certificate is installed, who owns it, how validation is done.
- Switch every certificate that can be DV to ACME, keep manual handling only where policy requires OV.
- Add external expiry monitoring for the whole list, not per-server crontabs.
- Standardize one validation method per domain, DNS based validation survives server moves best.
100 or more certificates
- Treat certificates as a service: central inventory, ideally cross-checked against Certificate Transparency logs so nothing issued outside your process goes unnoticed.
- Remove every manual issuance path, a certificate that automation did not issue is a bug.
- Delegate _acme-challenge zones so DNS-01 works without giving the automation full DNS control.
- Alert at 21, 14 and 7 days remaining, and assign an owner to every alert.
- Rehearse the 2027 limit now: if your process cannot handle 100-day certificates today, fix it before it becomes mandatory.
Where to go from here
This change punishes procrastination more than anything else: nothing breaks on 24 February 2026 by itself, but the first forgotten mid-term reissue after that date will take a site down. If you buy commercial certificates, check our SSL certificates, all plans include free mid-term reissues for the full paid term. If you would rather not own the renewal loop at all, our SSL automation service sets up ACME issuance, deployment and expiry monitoring on your servers and keeps it running.