Seven Months to 100-Day Certificates: A Prep Plan for March 2027

Since 15 March 2026, publicly trusted TLS certificates have been capped at 200 days. That was the first step of the CA/Browser Forum's ballot SC-081, which we covered when it passed last April. For teams already on ACME, it changed nothing. For teams buying annual certificates from a commercial CA, it meant a mid-year reissue that some of them discovered only when the CA's email arrived.

The next step lands on 15 March 2027: the maximum lifetime drops to 100 days, and the period a CA can reuse a domain validation drops to 100 days as well. That's seven months away, which sounds like plenty. It isn't much once you subtract the December change freeze and the time it takes to get a procurement answer from a CA account manager.

This post is the practical version: what the 100-day step actually changes, who it hurts, and a month-by-month plan to be done before it arrives.

What changes on 15 March 2027

Two numbers move at once:

The lifetime change is the one people talk about. The validation change is the one that causes more work.

Lifetime. At 100 days, a certificate has to be replaced at least four times a year, and realistically five or six once you renew with a sensible margin. If a human does each replacement, that's the end of "we do certificates once a year in January."

Validation reuse. When a CA issues a certificate, it has to have verified that you control the domain. Today that proof can be reused for up to 200 days; from March it's 100. If you validate by clicking a link in an email sent to admin@, or by adding a DNS TXT record by hand in a CA portal, you'll be doing that more often too, and with less slack between the validation expiring and the certificate needing renewal.

If you're fully on ACME with automated HTTP-01 or DNS-01 challenges, both changes are invisible. Your client validates on every issuance anyway. Everything below is about the certificates that aren't in that happy path.

Find the certificates that aren't automated

You can't plan for certificates you don't know about. Three places to look:

Certificate Transparency logs. Every publicly trusted certificate is logged. Searching your domains on crt.sh lists everything issued for them, including certificates issued by teams or vendors you didn't know about:

# every certificate logged for example.com and its subdomains, as JSON
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' \
  | sort -r | head -50

Look at the issuer column. Certificates from Let's Encrypt or another ACME CA that renew every 60 to 90 days are probably automated. Certificates from a commercial CA issued once or twice a year are your list.

Your live endpoints. CT tells you what was issued, not what's being served. Check the actual certificate on each hostname:

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

A certificate whose notBefore to notAfter span is close to 200 days, from a CA you pay, is a manual renewal waiting to become a quarterly problem. You can also paste a certificate into our certificate decoder or run a hostname through the SSL checker.

The places that aren't web servers. Load balancers where someone uploads a PEM file through a console. Mail servers. VPN appliances. Printers and IoT dashboards with public certificates. SaaS products where you uploaded your own certificate for a custom domain. These are the ones that don't show up in anybody's deployment pipeline.

Sort them into three buckets

For each certificate that isn't automated, decide which of these it is:

1. Could use ACME today. It sits on a normal web server or a load balancer with an ACME integration. Nothing is stopping it except that nobody has done it. Most certificates end up here.
2. Needs a commercial CA, but the CA has ACME or an API. Many commercial CAs now offer ACME endpoints with external account binding. The work is getting the credentials and pointing a client at them. Ask your CA now, not in February.
3. Genuinely manual. An appliance with an upload-only interface, a vendor-hosted custom domain with no API, a pinned certificate in a mobile app. These need a different answer: a vendor that supports automation, a reverse proxy in front that terminates TLS with an automated certificate, or a plan to replace the device.

The third bucket is what the next seven months are really for.

Fix validation once, not four times a year

For certificates that stay with a commercial CA, move off email validation. The better options, depending on your CA:

• DNS-01 via an API. Your ACME client creates the _acme-challenge TXT record through your DNS provider's API on every issuance.
• CNAME delegation. Point _acme-challenge.example.com at a record in a separate zone that only your certificate automation can write to. The production zone's credentials never touch the renewal job, and the delegation is set up once.

_acme-challenge.example.com.  CNAME  example.com.acme.validation.example.net.

While you're in the DNS console, check your CAA records. If you're adding a second CA or an ACME endpoint from your existing CA, make sure CAA allows it, or issuance will fail in a way that looks like a validation problem.

Use renewal information, not fixed timers

ACME Renewal Information (ARI) lets the CA tell your client when to renew, instead of the client renewing at a fixed number of days before expiry. It matters most during a mass revocation, when a CA needs a large number of certificates replaced quickly. Recent versions of the major ACME clients support it; check yours and turn it on if it's available.

A month-by-month plan

• August–September: inventory. CT search, live endpoint checks, and a spreadsheet with an owner for every certificate.
• October: move bucket 1 to ACME. Ask your commercial CA about ACME support for bucket 2 and get an answer in writing.
• November: bucket 2 migrations. Start conversations with vendors for bucket 3.
• December: change freeze for most teams. Use it to write down how renewals work, and who gets paged when one fails.
• January–February: bucket 3 fixes, and a deliberate test: break a renewal in staging and confirm something alerts.
• 1 March: final check. Anything still manual should have a named owner and a calendar entry for every renewal until it's fixed.

Monitoring gets more important, not less

Every renewal is a chance for a quiet failure: the challenge path blocked by a new WAF rule, the reload hook that stopped working, the timer lost in a server migration. At 100-day lifetimes you'll have twice as many renewals as today, each with less time between "renewal failed" and "visitors see a warning." We went through those failure modes in detail in our SSL certificate monitoring guide.

The fix is an outside check on the certificate each endpoint is actually serving, with thresholds sized for short lifetimes. CompleteStatus's SSL monitors read the live certificate, check the chain and expiry, and alert before it runs out, independent of whatever renews it. If you're doing the inventory step anyway, adding each hostname to a monitor as you find it is five minutes of work that pays off in March. See pricing for what each plan covers.