TLS certificates: from 398 to 47 days, manual renewal is over

The rules governing public TLS certificates are set by the CA/Browser Forum, which brings together certificate authorities and browser vendors. On April 11, 2025, it adopted ballot SC-081v3: 25 authorities in favor, none against, 5 abstentions, and a unanimous vote from the four browser vendors (Apple, Google, Microsoft and Mozilla). The text gradually cuts a certificate's maximum lifetime, which was 398 days, down to 47 days.

The reuse period for domain validation follows the same slope. Today, an authority can rely on proof of domain control that's several months old to issue a new certificate. In 2029, that proof will only be valid for 10 days: in practice, nearly every renewal will require a fresh validation, through a DNS record or an HTTP file.

Why shorten

A certificate attests that a key belongs to a domain at a given moment. The longer it lives, the more likely that attestation is to be wrong: stolen key, resold domain, certificate issued by mistake. In theory, revocation handles those cases. In practice it works poorly, because browsers don't all check revocation status on every connection, or ignore a failed check. The only reliable guarantee is therefore expiry. Let's Encrypt sums up the argument: short lifetimes limit exposure in case of mis-issuance or key compromise, and push toward automation, which makes them as easy as long ones.

Let's Encrypt's schedule

Let's Encrypt, the authority that issues the most certificates on the web, moves faster than the mandated schedule. Its certificates have always lasted 90 days. Since January 2026, 160-hour certificates (just over six days) are available to everyone on request, via the "shortlived" ACME profile. Since May 13, 2026, the "tlsserver" profile issues 45-day certificates for those who want to get ready. Then the default profile moves to 64 days on February 10, 2027, with 10-day validation reuse, and to 45 days on February 16, 2028, with reuse limited to 7 hours.

With 45 days of validity and renewal at two-thirds of the lifetime, a domain changes certificate about a dozen times a year, versus once with a 398-day certificate. What used to be done by hand once a year, with a calendar reminder, no longer holds.

What will break

• Certificates bought and installed by hand, on a server, a load balancer or a CDN: every manual copy becomes a scheduled outage.
• Mobile apps or API clients that pin the server certificate rather than the key or the authority: they break on every rotation.
• DNS validations done by hand: with 10-day reuse, you need programmatic access to the DNS zone, or HTTP validation.
• Forgotten subdomains (staging, an old back office) that nobody monitors: they expire without anyone noticing before a customer does.

# When does the certificate actually served expire?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

# certbot: renew whatever is due, then reload the web server
certbot renew --quiet --deploy-hook "systemctl reload nginx"

# Prefer ACME clients that support ARI (RFC 9773): the CA tells the
# client when to renew, including early renewal after a revocation.

If your host or CDN already manages the certificate (Vercel, Netlify, Cloudflare, most PaaS), the change is invisible. The risk concentrates on whatever doesn't go through them: self-managed servers, custom domains configured by hand, exposed internal services. And you need to monitor the certificate actually served, not the one you think you deployed.