TLS certificates drop to 100 days in 2027 and 47 in 2029. Here's what breaks, and how to automate renewals first

The next cut to certificate lifetimes comes on March 15, 2027. If anyone in your company still renews certificates by hand, find them now and automate them before the 100-day limit starts. Two years later the limit is 47 days, and a manual process can't keep up with that.

An expired certificate is one of the most avoidable outages there is, and big companies still have them. Ericsson said an expired certificate in its software was the main issue behind a December 2018 failure at several mobile operators it supplies. Its CEO apologised to the operators and to their customers too. Microsoft Teams went down in February 2020 because an authentication certificate had expired, as Microsoft's own status update said.

Shorter lifetimes multiply the chances. Each renewal is a moment where a manual step can be skipped, a password can be wrong or the person who knows the process is on holiday. At 47 days, with renewal usually done about two-thirds of the way through, a single certificate gets renewed roughly every month. Fifty certificates means about fifty renewals a month.

For engineers, the expiry date itself is the easy part. The harder change is domain control validationdefinitionThe CA's check that you still control a domain. You pass it by doing something only the owner can, such as publishing a DNS record.. A CA has to check you still control a domain before it issues a certificate for it, and the rules cap how long it can reuse an old check. That cap falls to 10 days in 2029, so in practice nearly every renewal triggers a fresh check. If your checks rely on someone clicking a link in an email, that person becomes part of every renewal.

You won't find this in a law. It comes from the CA/Browser Forum, where certificate sellers and browser makers agree the Baseline Requirements that every public certificate has to meet. Apple proposed the change as ballot SC-081v3 and it passed in April 2025. All four browser makers and 25 issuers said yes, five abstained, and nobody voted no.

Mostly, it's about revocation. The ballot calls a certificate a snapshot of the facts on one day. When those facts change, revocation lists and OCSP don't protect people well enough, while browsers do enforce expiry dates reliably. So a shorter life means a wrong or stolen certificate stops working sooner. Let's Encrypt already switched its OCSP responders off in August 2025.

Many issuers stay a little under the cap. DigiCert issues 199-day certificates, one day under the limit. AWS Certificate Manager and Azure App Service Certificates now issue 198-day ones. If a renewal tracker assumes exactly 200 days, it's already off by a day or two.

Cloud load balancers that renew their own certificates rarely cause trouble. The ones that do are installed by hand: on appliances, on older web servers, in vendor products with an upload screen. Watch for software holding its own copy of a certificate, too. Practitioners keep raising a few patterns.

• Pinned certificates. A Hacker News commenter who has to set their email provider's certificate fingerprint in their mail sync tool says the value used to change once a year and now changes every 47 days. Apps and integrations that pin a leaf certificate break on every renewal.
• Public certificates used for logins between systems. A Security Stack Exchange question asks for long-validity certificates for system-to-system client certificate logins. They also lose the client authentication purpose, and Microsoft says apps using App Service certificates for mTLS have to move to another method.
• Renewals that restart services at the wrong time. An open Vault issue asks for Vault Agent to hold renewed PKI certificates for a maintenance window unless expiry comes first, because a renewal and its exec command can reload Vault, HAProxy or a database at an uncontrolled time in production.
• Files rewritten when nothing changed. Another open Vault issue reports that Vault Agent rewrites a rendered certificate file on every render cycle, so a file watcher in the app reloads the service about every ten minutes.
• Email domain checks. If nobody re-verifies domain ownership, Azure says the App Service Certificate won't renew, and mail verification goes away in March 2027.
• Certificates outside the managed path. AWS says ACM certificates issued through its new ACME endpoint don't get ACM managed renewal, so your ACME client has to handle them.

There isn't one tool for this. Most estates end up with a mix: the cloud renews what it can, an ACMEdefinitionShort for Automated Certificate Management Environment, RFC 8555. You point an ACME client at a CA and it handles the request, the domain check and the renewal. client covers servers and Kubernetes, and a certificate management platform takes the inventory, ownership and the awkward appliances. Pick per endpoint type, starting with whatever gets renewed by hand today.

Vault's PKI secrets engine has run its own ACME server since 1.14. Internal clients can then use the same tools they'd point at a public CA. HashiCorp recommends External Account Binding for any public-facing Vault. On Vault Enterprise 2.0.0 and later, Vault Agent can also be the ACME client for a public CA, though only with the http-01 challenge. Our HashiCorp Vault page covers how we set up PKI engines and renewal.

If you know the product as Venafi, it's now CyberArk Certificate Manager. CyberArk acquired it, then Palo Alto Networks completed its purchase of CyberArk in February 2026, and the SaaS version now appears on its site as Next-Gen Trust Security. See our CyberArk page. ServiceNow shops can use Certificate Inventory and Management, which finds certificates and raises approvals and renewal tasks before expiry. It's useful when someone still has to touch the renewal. Our ServiceNow page has more.

# Check when the certificate this server actually serves expires
$ HOST=www.example.com
$ openssl s_client -connect $HOST:443 \
    -servername $HOST </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate -issuer
# Does it still carry client authentication?
$ openssl s_client -connect $HOST:443 \
    -servername $HOST </dev/null 2>/dev/null \
  | openssl x509 -noout -ext extendedKeyUsage
# cert-manager: is every certificate Ready?
$ kubectl get certificates -A
$ kubectl describe certificate <name> -n <ns>

These are generic illustrations, not client stories. Your own estate will mix several of them.

We find every certificate you have, work out how each one renews, and move the manual ones to ACME, a managed service or a certificate platform. We also set up private PKI on HashiCorp Vault for internal traffic. If you'd rather add engineers to your own team, see hiring Vault engineers. To find out where you stand first, start with our assessment.