From March 15, 2027, publicly trusted TLS certificates can be valid for at most 100 days, down from the 200-day limit in force since March 2026 and the 398 days that applied until then. On March 15, 2029, the limit falls again, to 47 days. At the same time, how long a certificate authority can reuse proof that you control a domain shrinks in parallel, to just 10 days by 2029. Any certificate still installed by hand, on any service of any server, becomes a recurring outage risk. The answer is not faster manual renewal. It is automation that covers issuance, installation on every service that uses the certificate, and monitoring that does not depend on the certificate authority reminding you.

For most hosting environments, web traffic is already handled: Let's Encrypt and ACME automation have been standard for years. The problems in 2027 will come from the exceptions: paid certificates installed manually, mail and FTP services that do not reload, wildcard certificates that depend on DNS, and systems nobody remembers are using a certificate at all.

The schedule, and the part people miss

The CA/Browser Forum, the industry body whose requirements browsers and operating systems enforce, adopted Ballot SC-081v3 in April 2025. It sets two parallel schedules, applied by issuance date:

Certificates issued fromMaximum validityDomain validation reuseBefore March 15, 2026398 days398 daysMarch 15, 2026200 days200 daysMarch 15, 2027100 days100 daysMarch 15, 202947 days10 days

The second column gets the headlines. The third is the more disruptive change. Domain control validation (DCV) reuse is the period during which a certificate authority may rely on an earlier proof that you control a domain, whether a DNS record, an HTTP file or an email approval, without asking again. Today, many commercial certificate workflows validate a domain once a year and then reissue freely. At 10 days, validation becomes effectively continuous: every renewal will require a fresh proof, performed automatically.

For organisation-validated (OV) and extended validation (EV) certificates, identity information about the company can still be reused for longer, but the domain validation and certificate lifetimes follow the same schedule. A paid EV certificate in 2029 has the same 47-day cadence as a free domain-validated one.

Why the industry is doing this

The reasoning in the ballot is straightforward. A certificate states facts: this key belongs to this domain, and possibly this organisation. The longer a certificate lives, the more likely those facts have changed while the certificate stays valid: the domain changed hands, the key leaked, the server was decommissioned. Revocation was supposed to handle those cases, but in practice it has worked poorly. Browsers check revocation inconsistently, and the infrastructure behind it is costly. Let's Encrypt ended its OCSP service in 2025 for exactly this reason. Shorter lifetimes limit how long a wrong or compromised certificate can be abused, without depending on revocation.

The side effect is intended: manual certificate management becomes impractical. That is the point of the schedule.

What Let's Encrypt is doing on its own timeline

Let's Encrypt already issues 90-day certificates, well within the 2027 limit, so sites that use it are unaffected by the March 2027 step itself. But it has announced its own reduction to 45 days, one year ahead of the industry's 47-day requirement:

• Since May 13, 2026, an opt-in ACME profile (tlsserver) issues 45-day certificates, so administrators can test short lifetimes now.

• The default profile is scheduled to move to shorter certificates in stages, reaching 45 days by February 16, 2028. Authorisation reuse periods will also be reduced.

There is also a change that has already caused outages. Let's Encrypt stopped sending certificate expiry notification emails in 2025. Many administrators discovered broken renewals only because of those emails. If your only monitoring was an inbox, you no longer have any.

Where hosting servers break

Web servers with a working ACME client usually renew without incident. Failures cluster in the places listed below, and every one of them is more likely at a 100-day cadence than at a yearly one, simply because renewals happen three to four times more often.

Certificates installed by hand

Paid OV or EV certificates are the most obvious weak point. The traditional workflow looks like this: generate a CSR, submit it to the vendor, validate the domain, download the certificate and chain, paste them into a control panel or copy them to the server, and reload. Doing that once a year is tolerable. Doing it every 100 days, then every 47 days, across dozens of domains, is not.

Most commercial certificate authorities now offer ACME endpoints for their paid products, usually with account-binding credentials (External Account Binding) so the ACME client is tied to your paid account. Switching from manual installation to an ACME client pointed at the vendor's endpoint keeps the OV/EV identity while automating the renewal mechanics. If your vendor does not offer ACME, that alone is a reason to reconsider the vendor before March 2027.

Services that use the certificate but never reload

On a typical hosting server, the same certificate is often used well beyond Apache: the SMTP server (Postfix, Exim), IMAP and POP (Dovecot), FTP over TLS, the control panel's own HTTPS port, sometimes a database or a mail filtering proxy. An ACME client renews the certificate files on disk. It does not automatically tell those other services to load the new files.

The failure pattern is subtle. The website shows the new certificate, and everything looks fine. Days or weeks later, mail clients start rejecting connections because Dovecot is still serving the old, now-expired certificate from memory. With certbot, the fix is a deploy hook, a script that runs only after a successful renewal:

bash

#!/bin/sh
# /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh
# Runs after each successful renewal; $RENEWED_LINEAGE points to the live directory.
set -e
systemctl reload apache2
systemctl reload postfix
systemctl reload dovecot

Make the file executable. Certbot runs every executable script in that directory after any successful renewal. List every service that references files under /etc/letsencrypt/live/. A quick grep -r "/etc/letsencrypt/live" /etc/ usually reveals a few you had forgotten.

Apache's own ACME module

Apache 2.4 includes mod_md, an ACME client built into the web server. It obtains and renews certificates for the domains you declare and uses them in matching virtual hosts:

apache

MDomain example.com www.example.com
MDCertificateAgreement accepted

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
</VirtualHost>

It handles the web side cleanly. But Apache needs a reload to activate a renewed certificate, and other services still need their own copy and their own reload. mod_md can run a notification command when a certificate is renewed, which you can use for this. With either approach, the question to answer for each server is the same: which processes hold this certificate in memory, and who tells them it changed?

Validation that fails silently

HTTP-01 validation requires the certificate authority to fetch a file under /.well-known/acme-challenge/ over plain HTTP. On shared hosting, several ordinary configurations break it: an .htaccess redirect that catches the path, a maintenance mode, a web application firewall rule, a geo-blocking rule that rejects the validation servers, or an application that handles all paths through a front controller. None of these break the site, so nobody notices until the renewal fails.

At a 100-day cadence, a renewal typically starts about a month before expiry, so a validation failure has several weeks to be noticed. At 47 days and 10-day DCV reuse, the margin shrinks considerably.

Wildcard certificates require DNS-01 validation, publishing a TXT record in the zone. Automating that requires API access to the DNS provider, or a delegated validation zone via a CNAME, so that the ACME client can create the record. If your wildcard renewals depend on someone adding a TXT record by hand, that process has to be automated before 2027.

CAA records are the other quiet cause of failure. A CAA record in DNS lists the certificate authorities allowed to issue for a domain:

text

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"

If a site moves to a different CA, or a paid certificate is ordered from a vendor not listed in the CAA record, issuance fails. The CAA record is correct and useful for security, and it should be part of the certificate inventory rather than an afterthought.

Many domains, many lifecycles

The renewal workload scales with hostnames, not with sites. A single brand operating under several domains, whether country-specific storefronts, a news publisher with regional editions, a SaaS product with customer-specific subdomains, or an entertainment property such as the Crazytower site, carries a certificate lifecycle for every domain it serves, each with its own validation and its own failure modes. On shared hosting platforms, a provider may be responsible for thousands of such lifecycles at once. At 398 days, an unmonitored renewal failure on a rarely visited domain could go unnoticed for most of a year. At 100 days, and then 47, a platform without per-domain monitoring will see expiry outages as a steady background rate, not a rare event.

Monitoring that does not rely on the CA

Automated renewal is only half of the solution. The other half is independent verification that the certificate actually being served, on every port, is valid and not close to expiry.

A minimal check uses OpenSSL against the live service rather than reading files on disk:

bash

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

# SMTP submission with STARTTLS
echo | openssl s_client -connect mail.example.com:587 -starttls smtp 2>/dev/null \
  | openssl x509 -noout -enddate

# IMAPS
echo | openssl s_client -connect mail.example.com:993 -servername mail.example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Checking the served certificate, not the file, is what catches the "renewed on disk, stale in memory" failure. Wrap these checks in your existing monitoring system and alert on two conditions: a certificate expiring within a set threshold, and a certificate that should have been renewed but was not. At a 100-day cadence, alerting when less than about 20 days remain leaves time to react. With 47-day certificates, clients typically renew with a few weeks remaining, so the alert threshold needs to be tighter.

The ACME protocol also has a newer mechanism for handling renewal timing. ACME Renewal Information (ARI) lets the certificate authority tell clients when to renew, for example to spread load, or to trigger early renewal if a batch of certificates must be revoked. Client support is growing. When choosing or updating an ACME client, ARI support is worth checking, because it allows mass reissuance events to be handled without manual intervention.

A practical preparation plan before March 2027

Build an inventory. List every certificate in use: domain, issuer, validation method, how it is installed, and which services use it. Include control panel ports, mail services, load balancers, CDNs and appliances. Most organisations underestimate this list.

Eliminate manual installation. Move every certificate to an ACME client, including paid ones, via the vendor's ACME endpoint. Any certificate that cannot be automated should be treated as a known risk with a named owner.

Automate deployment, not just issuance. Add deploy hooks or equivalent for every service that uses each certificate, and test them by forcing a renewal on a staging certificate.

Automate DNS-01 for wildcards and any domain where HTTP-01 is unreliable, using a DNS provider with an API or a delegated validation zone.

Check CAA records against the CAs you actually use.

Test short lifetimes early. Let's Encrypt's 45-day opt-in profile and its staging environment let you run your automation at 2028–2029 cadences today. If something breaks at 45 days, better to find out now than in March 2029.

Monitor served certificates independently, on every port, with alerts that do not depend on email from the CA.

Beyond 2027

The 2027 step is the one that forces the change. At 100 days, the teams that still install certificates by hand will spend a noticeable share of their time on renewals, and will experience outages. The 2029 step to 47 days, with 10-day DCV reuse, then makes any remaining manual process effectively impossible. Hosts that build complete automation this winter, covering issuance, deployment to every service and independent monitoring, will barely notice either date. The rest will learn about them from their customers.