TLS Certificates Drop to 100 Days on 15 March 2027. Automating Renewal Is the Easy Half.

Since 15 March 2026, publicly trusted TLS certificates have been capped at 200 days. The next step is 100 days for certificates issued from 15 March 2027, and 47 days from 15 March 2029, under CA/Browser Forum ballot SC-081v3. Secondary summaries such as SSL.com's guide to the DCV reuse policy cover the schedule; check the ballot text itself before you put exact dates in a runbook. The usual advice is to turn on ACME and move on. That fixes the certificates you know about. The outage comes from the ones you do not.

The schedule for TLS certificate lifetimes

Two clocks tighten together: the maximum certificate lifetime, and how long a CA may reuse a successful domain control validation before asking you to prove control again. Both matter, because a certificate you can renew only if someone clicks an approval email is still a manual process.

The last column assumes you renew at two-thirds of lifetime, a common practice that leaves a buffer for failures. At 47 days that is a renewal roughly every 31 days. Ten manually managed certificates go from about ten renewals a year to well over a hundred. Nobody sustains that by calendar reminder.

Two details help. The limits apply by issue date, so nothing already issued is shortened. And they bind publicly trusted CAs only; a private CA can still issue whatever lifetime you configure.

Inventory is the real problem

Teams with ACME on their main web tier will pass the 2027 date without noticing. The certificates that fail are the ones that never entered the system. Look in these places:

• Load balancers and CDNs where a certificate was uploaded once through a console.
• Partner-facing endpoints that use mutual TLS, where the partner pins your certificate or its fingerprint.
• Appliances: VPN concentrators, mail gateways, monitoring tools, printers with web interfaces.
• Webhook receivers and SFTP or API gateways run by one engineer who has since left.
• Certificates issued to a vendor on your behalf, such as a status page or a marketing subdomain.

A weekend audit you can run now

Start with what the internet can see. Certificate Transparency logs record every publicly trusted certificate issued for your domains, including ones you have forgotten. Search your domains there, group the results by issuer, and compare the list to what your automation actually manages. The gap is your risk.

Then check live expiry on every hostname you find, including non-standard ports. This one-liner prints the expiry date of the certificate a host presents:

for host in api.example.com mtls.example.com sftp.example.com; do
  end=$(echo | openssl s_client -servername "$host" -connect "$host:443" 2>/dev/null \
        | openssl x509 -noout -enddate | cut -d= -f2)
  echo "$host expires $end"
done

Feed the output into whatever already pages you, and alert at 21 days and 7 days before expiry. When lifetimes drop to 47 days, scale those thresholds down; a 21-day warning on a 47-day certificate fires almost half way through its life.

Automate validation as well as issuance

With ACME, issuance is a script. Domain control validation is where teams stall. DNS-01 validation needs an API credential that can write TXT records, and handing a broad DNS credential to every server is a security trade-off. A common pattern is to delegate the challenge subdomain to a dedicated zone with narrow permissions, so a compromised host can only create challenge records.

HTTP-01 is simpler but needs port 80 reachable and does not cover wildcards. Email-based validation is the one to retire first: it depends on a person reading a message, and the 10-day reuse window in 2029 makes that unworkable.

What to do before March 2027

Five months is enough time if you start with inventory. List every certificate, assign an owner, move what you can to ACME, and write down the rest as known exceptions with a named person and a renewal date. Test one failure on purpose: let a non-critical certificate expire in staging and see who notices first. The answer tells you whether your alerting is ready for a 47-day world, where a missed renewal is a routine event rather than a rare one.