How to Prepare for Shorter SSL Certificate Lifetimes (47-Day Certificates)

What is changing, and when?

The schedule is fixed, public, and shorter at every step than most teams assume. A certificate keeps whatever validity it was issued with — nothing already installed becomes invalid on a deadline day — but everything issued after each date obeys the new ceiling.

Two numbers in that timeline deserve more attention than the headline lifetime. First, domain validation reuse: today a CA can reuse your proof of domain control for up to 200 days, but by March 2029 that window is 10 days, which means validation effectively happens at every issuance. Second, the OV/EV identity reuse window stays at 398 days, so organization vetting remains a roughly annual event even when the certificates themselves turn over every few weeks. The mechanics of the vote and the reasoning behind it are covered in our guide to the 2026 lifetime changes; this page is about what to do with that information.

How many renewals will you actually be doing?

The arithmetic is what turns a policy story into an operations problem. One certificate on one domain is fine at any cadence. Twenty certificates across web servers, load balancers, mail, and a staging environment is a different job at 47 days than it was at 398.

There is a second-order effect the table hides: renewals stop being an event and become background load. At 47 days you want certificates replaced around day 30, which means something in your estate is renewing more or less continuously. Our 199-day certificate explainer walks through why CAs issue just under the ceiling and how the renewal window math works today.

Will shorter SSL certificate lifetimes cost more?

No — and this is the most common misunderstanding we field. What you buy from a CA is a coverage period; the certificate files issued inside that period are just artifacts of it. A multi-year order today already works this way: the CA cannot hand you a three-year certificate, so you reissue within your paid term and each reissue costs nothing. Shorter lifetimes increase how often that reissue step happens. They do not change the price of the term.

The cost that does change is operational. Every manual renewal has a labor price and a risk price, and both scale with frequency. That is the honest argument for sorting automation out in 2026 rather than during the 2027 transition. If you are still buying year to year, this is also the moment to look at multi-year coverage — you lock the price once and reissue as often as the rules require; you can compare multi-year SSL certificate plans to see how the terms are structured.

Step 1: Inventory every certificate you run

You cannot automate what you have not found, and every estate we have looked at contains certificates nobody remembered. The web server is the easy part. The ones that cause 2 a.m. pages live elsewhere: load balancers, mail servers, API gateways, internal admin panels, the CDN configuration someone set up in 2023, IoT gear, and the staging box that quietly serves production traffic for one legacy client.

Build the list with hostnames, where each certificate terminates, who issued it, its expiry date, and — the column everyone forgets — how it got there. "Certbot cron job" and "Marek uploads it through the panel" are very different risk profiles even when the expiry date is identical. For the public-facing entries, you can run each hostname through our free SSL checker to pull issuer, expiry, and chain details without logging into anything.

Score each row by renewal method, not by expiry date. Anything renewed by a human hand is a migration candidate. Anything renewed by a machine needs its renewal path tested, which is Step 4's job.

Step 2: Pick your automation path

There is no single right answer here — there is a right answer per system, and the decision is mostly made for you by what each system supports.

If the system speaks ACME, use ACME. Certbot, acme.sh, Caddy, Traefik, and cert-manager on Kubernetes all handle issuance and renewal end to end, and ACME is exactly the protocol this industry change was designed around. Wildcard certificates force the DNS-01 challenge, which means your DNS provider needs an API the client can drive — if yours does not have one, moving DNS is cheaper than hand-renewing a wildcard eight times a year. Our Certbot and ACME automation guide covers the setup end to end, including the renewal timer most people forget to verify.

If it lives in a hosting panel, use the panel's machinery. cPanel's AutoSSL and the Plesk certificate extensions renew on their own once enabled. The trap is the middle case: a paid certificate bought elsewhere and pasted into the panel manually. That workflow is already the most common source of expiry incidents we see, and it gets eight times worse by 2029. Either let the panel manage issuance or terminate TLS somewhere that automates.

If it is a cloud load balancer or CDN, let the platform own it. AWS Certificate Manager, Cloudflare, and their equivalents renew their own certificates invisibly. The work is confirming which listeners actually use platform-managed certificates and which have a manually uploaded one with an expiry date nobody owns.

If it cannot automate at all — an appliance with a web UI from 2015, a vendor box that only accepts pasted PEM files — isolate it on the inventory, put its renewal on a named person's calendar at half the certificate lifetime, and plan its replacement. By 2029 "cannot automate" and "cannot keep online" describe the same device.

Step 3: Plan around shrinking validation windows

Lifetimes get the headlines, but the validation reuse changes bite just as hard. Domain control validation reuse fell to 200 days in March 2026, tracks the certificate lifetime down to 100 days in 2027, and collapses to 10 days in 2029. At that point validation is not something you did last quarter — it is part of every single issuance.

The practical consequence: your validation method has to be as automated as your issuance. HTTP-01 and DNS-01 challenges handled by an ACME client satisfy this by construction. Email-based validation does not — an approval email that a human clicks every 47 days, forever, across your whole estate, is a standing outage generator. If any certificate on your inventory still validates by email, moving it to a file-based or DNS-based method is a 2026 task, not a 2029 one.

OV and EV certificates keep their 398-day identity-reuse window, so the organization vetting stays an annual rhythm. But the domain-control half of an OV or EV issuance follows the same shrinking clock as everything else. In practice that means OV/EV automation is a split workflow: identity paperwork once a year through the CA's portal, domain proof continuously through your tooling.

One config-level item worth doing while you are here: publish CAA records naming the CAs allowed to issue for your domains. It costs ten minutes, it prevents an entire class of mis-issuance, and it removes a surprise during automated issuance later.

Step 4: Monitor renewals like they can fail

Automation does not remove failure; it changes its shape. The renewal failures that reach our support queue are rarely exotic — an ACME client that stopped running after an OS upgrade, a DNS API token that expired, a firewall change that broke the HTTP-01 path, a CAA record added by another team. Every one of them was invisible until a certificate expired.

So monitor the outcome, not the mechanism. An external check on each public endpoint that alerts when a served certificate has less than a third of its lifetime remaining will catch every failure mode at once, including the ones you have not imagined. At 90-day lifetimes that alert threshold is 30 days; at 47-day lifetimes it is roughly 15, and the window between "alert" and "outage" gets short enough that the alert needs to page someone, not sit in an inbox.

Test the failure path once, deliberately. Break a renewal on a staging host — revoke the DNS token, block the challenge — and watch what happens. If the answer is "nothing alerted until the certificate expired," you have found your real project. What an expiry actually costs when it lands in production is documented in our certificate expiration outages post-mortem guide.

Newer ACME clients also support the ACME Renewal Information (ARI) extension, which lets the CA itself tell the client when to renew — including early, if a revocation event or an incident requires it. As lifetimes shrink, turning ARI support on where your client offers it moves one more decision from a human calendar to the protocol.

ARI is also about to stop being optional on the CA side. Under Chrome Root Program policy, every publicly trusted CA has to provide automated issuance and renewal for every certificate profile from March 15, 2027, OV and EV included — which lands on the same day lifetimes drop to 100 days.

Your 2026–2029 preparation timeline

Sequenced so that each phase makes the next one boring:

• Now through Q1 2027: Complete the inventory. Enable ACME or panel automation on every system that supports it. Move wildcard issuance onto DNS-01 with an API-driven DNS provider. Replace every email-validated certificate with file- or DNS-based validation. Publish CAA records.
• March 2027 — the 100-day era begins: Everything issued from here renews roughly quarterly. Manual paths that survived this far now fail visibly; treat each incident as the argument for finishing the migration rather than as bad luck.
• 2028: Retire or replace the systems on the "cannot automate" list. Tighten monitoring thresholds to the shorter lifetimes and confirm alerts page a human. Test one deliberate renewal failure per quarter.
• Before March 2029: Confirm every issuance path handles 10-day validation reuse — meaning validation runs unattended at every renewal. Enable ARI where your ACME client supports it. At this point a 47-day certificate is just a shorter number in a system nobody touches.

Methodology and review

Dates and reuse periods in this guide follow CA/Browser Forum Ballot SC-081v3 as implemented by the major CAs, cross-checked against DigiCert's 199-day issuance notice and the published Sectigo and SSL.com transition guidance. The renewal-frequency table is arithmetic on the published maximums, assuming replacement at roughly two-thirds of lifetime, which is the convention ACME clients default to. Operational failure patterns come from My-SSL's own support experience as a Certum partner — described qualitatively, because our ticket queue is not a statistically clean dataset and we prefer not to dress it up as one.

Written by Daniel Rehak, TLS and PKI engineer at My-SSL.com. Technically reviewed by the My-SSL Security Team on August 7, 2026. We re-check this page at each SC-081 milestone and whenever a CA announces an implementation date that differs from the ballot schedule.

Frequently asked questions