A TLS certificate used to be a maintenance item you thought about once a year: issue it, install it, forget it for twelve months. That era is over. In 2025 the CA/Browser Forum – the joint body of certificate authorities and browser makers – decided with Ballot SC-081v3 to cut the maximum lifetime of TLS certificates in stages, from today's 398 days (CA/Browser Forum) down to 47 days (CA/Browser Forum) by 2029. The first reduction to 200 days (CA/Browser Forum) already takes effect on 15 March 2026. For shop operators this moves a seemingly trivial task to a critical spot: anyone who keeps steering renewal by hand through calendar reminders raises the number of renewals to roughly eight times by 2029 – and every forgotten certificate takes the shop offline instantly with a full-screen security warning. This guide explains why lifetimes are shrinking, what the schedule means in practice and how ACME-based automation turns renewal into an invisible building block of ongoing shop maintenance.
Key takeaways
- With Ballot SC-081v3 the CA/Browser Forum cuts the maximum certificate lifetime in three stages: to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 (CA/Browser Forum). Today the ceiling is 398 days (CA/Browser Forum).
- An annual routine turns into a task that comes around every six to seven weeks by 2029 -- roughly eight times as often as today. At that frequency, manual renewal driven by calendar reminders is hardly reliable any more.
- An expired certificate is not a creeping problem but an immediate total outage: every common browser blocks access with a full-screen warning page. There is no partial function and no grey area.
- The workable answer is automation via the ACME standard (RFC 8555, IETF): a daily service checks the remaining lifetime, renews in good time, places the files where the web server expects them and reloads the service without downtime.
- Automation lowers the risk but does not remove it. A changed DNS token, a rate limit or a failed reload can make renewal fail silently -- which is why independent expiry monitoring belongs to every serious ACME setup.
Why TLS Lifetimes Are Shrinking at All
Behind the reduction lies a security rationale: the shorter a certificate is valid, the smaller the window in which a stolen private key or a wrongly issued certificate can be misused. The established revocation mechanisms – certificate revocation lists (CRL) and the online status service OCSP – are considered unreliable in practice, because browsers often silently ignore a missing revocation response. Short lifetimes act like a built-in expiry: a compromised certificate soon disappears on its own anyway. Google had already charted this direction with its 'Moving Forward, Together' roadmap in 2023 and floated a ceiling of 90 days (Google). The formal ballot was brought forward by Apple (Apple) and adopted in April 2025 within the CA/Browser Forum (CA/Browser Forum).
The economic backdrop makes the matter urgent. German online retail with consumers turned over around 83.1 billion euros (bevh) in 2025, at an average order value of 146.19 euros (bevh). Every minute a shop is unreachable because of an expired certificate costs revenue and trust directly – and unlike with a sluggish server, customers here do not see a slow page but a red warning that cautions against the operator's own domain. How expensive such an outage becomes depends on the business model; the order of magnitude can be estimated with the cost of downtime per hour.
In brief: what the CA/Browser Forum decided
The Schedule: From 398 to 47 Days
The reduction does not happen all at once but in three stages over a little more than three years. That gives operators time to adjust their processes – but only if they start now. The overview below shows the effective dates, the maximum lifetime allowed at each step, the shrinking reuse of the domain check and the number of renewals this produces per year and certificate.
| Effective date | Max. lifetime | DCV reuse | Renewals per year |
|---|---|---|---|
| Today (since 2020) | 398 days | 398 days | about 1 |
| from 15 Mar 2026 | 200 days | 200 days | about 2 |
| from 15 Mar 2027 | 100 days | 100 days | about 4 |
| from 15 Mar 2029 | 47 days | 10 days | up to 8 |
The last column is the real explosive charge. An annual routine becomes a task that comes around every six to seven weeks in 2029 – roughly eight times as often as today. Certificate authorities such as DigiCert and Sectigo draw the same conclusion: at this frequency, manual renewal is hardly reliably feasible any more (DigiCert; Sectigo). Anyone running several domains, subdomains and test environments multiplies the effort further. A process based on calendar reminders and copy-and-paste no longer scales here.
What Happens When a Certificate Expires
Unlike many maintenance lapses, an expired TLS certificate is not a creeping problem but an immediate total failure. The moment validity ends, every common browser shows a full-screen warning page – for example the message NET::ERR_CERT_DATE_INVALID – and blocks access. The shop is technically still online but practically unreachable for customers: the payment flow breaks off, search-engine crawlers hit errors, and pages linked in price comparisons or ads lead nowhere. An expired certificate thus behaves like an unplanned outage, with the added twist that the error message explicitly warns against the page and damages trust on top.
No grey area, just off
ACME: Automation Instead of a Calendar Reminder
The answer to shorter lifetimes is not a denser reminder list but full automation of renewal. The industry standard for this is ACME (Automatic Certificate Management Environment), specified in RFC 8555 (IETF). Through this protocol a server proves to the certificate authority on its own that it controls the domain, requests a new certificate and has it delivered – without a human stepping in. The approach became known through the free certificate authority Let's Encrypt, which already issues certificates valid for only 90 days (Let's Encrypt) and recommends renewal after 60 days (Let's Encrypt). Anyone already renewing automatically there has essentially pre-empted the 47-day future.
The decisive point: with short lifetimes, automation is not the convenient option but the only viable one. A process that would have to be carried out by hand every six weeks without a single slip will inevitably be forgotten once over the months – during a holiday, a staff change or the daily grind. ACME automation, by contrast, runs as a background service, checks the remaining validity daily and renews in good time before expiry. This shifts the maintenance task from 'remember in time' to 'monitor that the automation runs' – a far more robust class of error.
ACME client
An established ACME client requests certificates automatically, proves domain control and places the renewed files in the right location.
Challenge method
The domain check runs via HTTP-01 through a file in the webroot or via DNS-01 through a TXT record – the latter also for wildcard certificates.
Reload hook
After each renewal, a hook reloads the web server so the fresh certificate goes live without a manual restart and without dropping connections.
Expiry monitoring
An independent watcher measures the remaining validity from the outside and raises an alarm if the automation fails to fire despite everything.
Staging test
First runs are checked against the authority's test endpoints before going live, to avoid rate limits and misconfiguration.
Log
Every issuance is documented with time, validity and serial number so the certificate inventory stays traceable at any moment.
Why manual processes tip over now
What the Change Means in the Shop in Practice
For a typical Shopware or WordPress shop, the path to automatic renewal is manageable but demands care at the handover points. The ACME client must not only fetch a new certificate but also place it where the web server expects it and reload the service cleanly. If the reload hook is missing, a valid certificate sits on disk while the old one is still being served – until it expires. Such silent gaps are the most common reason a supposedly automatic setup nevertheless runs into an outage.
- Take inventory: record all domains, subdomains, redirect hosts and test environments that need a certificate.
- Set up the ACME client and choose the right challenge method – HTTP-01 for single hosts, DNS-01 for wildcards.
- Schedule renewal as a background service that checks daily and renews in good time before expiry.
- Set up a reload hook that reloads the web server or load balancer after renewal without dropping connections.
- Add external expiry monitoring that alerts independently of the automation.
- Secure the first run in a test environment against the authority's staging endpoints, then switch to production.
# Daily renewal run via cron or a systemd timer
# The client checks remaining validity and renews only when needed
# /etc/cron.d/acme-renew
0 3 * * * root acme.sh --cron --home /etc/acme >> /var/log/acme.log 2>&1
# Reload hook: reload the web server after a successful renewal
# --reloadcmd "systemctl reload nginx"
# Independent check of remaining validity from the outside
echo | openssl s_client -connect your-shop.com:443 2>/dev/null \
| openssl x509 -noout -enddateThe flow above is deliberately schematic – the concrete implementation depends on server environment, web server and hosting. What matters is the pattern: a daily running service, a reload without downtime and an independent check. It is exactly this interplay that separates resilient automation from a script that quietly fails when it counts. In a managed contract with security updates and hardening, certificate upkeep is one of the tasks that run in the background without the operator having to worry about deadlines.
Special Cases: Wildcards, Many Domains, Load Balancers
Not every shop consists of a single domain on a single server. As soon as wildcard certificates, several second-level domains, a content-delivery setup or a load balancer are involved, automation branches out. Wildcard certificates – for example for all subdomains of a brand – can only be renewed via the DNS-01 challenge, which requires programmable access to the DNS zone. This point is closely tied to the upkeep of DNS and DNSSEC. If a load balancer spreads traffic across several nodes, the renewed certificate must arrive on all nodes in sync before the old state expires.
- Renew wildcard certificates via DNS-01 with programmable access to the DNS zone.
- Distribute the new certificate in sync across several nodes behind a load balancer.
- Move expiring certificates from different providers onto one unified ACME process.
- Respect the authority's rate limits and test first runs against staging endpoints.
- Do not forget internal services and test environments – they too will run on short lifetimes.
- Keep the contact address for the authority's expiry warnings current.
Monitoring: The Second Net Under the Automation
Automation lowers the risk but does not remove it entirely. A changed DNS record, an expired API token for the DNS challenge, a rate limit or a failed reload can cause renewal to fail silently. That is why every serious ACME setup includes independent expiry monitoring that measures remaining validity from the outside – the same way uptime monitoring watches availability. If the watcher raises an alarm, say, 20 days before expiry, there is enough time to find the cause before customers ever see a warning. This separation of the acting and the checking system is the core of any reliable maintenance.
Certificate upkeep does not stand alone. It is part of an ongoing technical hygiene that also includes protecting customer accounts from automated takeover attempts and dealing with the growing load from AI crawlers. All three topics share the same core: a shop is a system that changes under observation, and whose boundary conditions – certificate lifetimes, attack patterns, request volume – shift independently of the operator. Maintenance means noticing these shifts early and reacting to them automatically.
Short certificate lifetimes punish every manual process and reward every clean automation. The real change is not technical but organisational: away from a date in the calendar, towards a monitored service.
How We Bring TLS Into Ongoing Maintenance
In our maintenance packages, certificate upkeep is a fixed, recurring building block – closely interlocked with security updates, monitoring and backups. It starts with an inventory: which domains and subdomains are in use, which certificates expire when, and how are they renewed today? On that basis we set up the ACME automation, add reload hooks for the respective web server and place independent expiry monitoring on top. The switch is done in a controlled way so that no certificate ever slips through between the old and the new process.
For shops that already run systematic certificate management, the step to 47 days is mainly a matter of frequency and monitoring. For operators who have renewed annually by hand so far, it is the right moment to rework the process fundamentally – well before the first effective date in March 2026. What the right scope looks like for a specific shop can be clarified in a short inventory; you can request such an analysis without obligation.