March 15, 2027, cuts public TLS to 100 days. Manually renewing will not be the way to go through the chop.
Six months left. On March 15, 2027, new public TLS drops to 100 days. TLS 200-day is now available. The renewal process will not change from twice a year to quarterly, plus new DCV. Browsers and CAs reduce the time a stolen key/mis-issued cert will be trusted. What changes, why ops breaks, 5 fixes, and how to automate before 2029.
Key Takeaways
- The public TLS certificate is already 200 days. On March 15, 2027, max lifetime and domain validation reuse are reduced to 100 days (four renewals per year for the certificate).
- That’s a rhythm spreadsheets, tickets, and calendar reminders don’t enjoy.
- Then March 2029 shortens the involvement to 47 days and DCV reuse to 10 days. The dress rehearsal is a hundred days, not the MEAT.
- Prepare for inventory, ownership, and sunset validation and deploy paths, and automate up to March 2027.
- There are a number of different ways to go – ACME is one, AutoInstall SSL is another, and CLM platforms are yet another. Select by the “Environment,” not by the vendor’s slogan.
What Changes on March 15, 2027?
Two rules roll out simultaneously. The validity of the Max certificate is reduced to 100 days. Domain/ip validation reuse also falls to a whopping 100 days.
Those clocks differ. The trust will be held for a lifetime by browsers. You own this domain” proof can be reused; for how many years can they be kept? That proof shall be from within 100 days of its issuance after March 15, 2027.
Issuing (not expiring) cap hits. If you’ve obtained a certificate that was valid for 200 Days and on 02/2024, you will still get the 200-day certification. All certs from 15 March 2027 onwards expire after 100 days.
Same-day Side Rules: CAs retire phone DV and reverse-lookup IP validation; email/fax/SMS/postal to an IP contact. ClientAuth EKU is no longer trusted by Chrome to accept new public TLS subscriber certificates.
The data comes from the CA/Browser Forum Baseline Requirements (CA/BFR), SC-081v3, the relevant document.
Why 100-Day TLS Is an Operational Challenge
The calculations used in math are rudimentary. The certificate was valid for 398 days and required an average of one renewal annually. Two hundred days was double that. There are four renewals you’ll receive in 100 days.
Forty-seven days later advances that certificate to nearly eight. The traditional annual habit teams still need to multiply their efforts by 4 in 2027, NOT 2029!
Domain validation is no longer a single activation process. Each issue may need to create a live HTTP-01, DNS-01, or other permitted method, as the CA cannot be able to reuse proof that’s any more than 100 days old.
Also Read: What are Certificate Outages? How to Avoid SSL Certificate Outages with ACME?
Two hundred days passed while they slowly changed their boards, split their ownership from app to network, DNS to security, and certificates were left in appliances, CDNs, load balancers, Kubernetes ingress, and vendor SaaS custom domains.
No shadow or orphan certs get added to the CMDB. That loose becomes tight when the clock is at 100 days.
The first 100-day certificates, which began on 16 March 2027, are beginning to expire in late June 2027. It would be the first true outage season if automation comes late.
Why Manual Renewal Becomes Risky in the 100-Day Era
It can be risky to go with manual renewal in the 100-day era. Manual Renewal starts to become risky in 100-Day Era.
The old process was as follows: calendar reminder, ticket, CSR, email DCV, wait, download, install, back on to calendar and hope the connection is done. That process relied on months of Slack.
At 100 days, Slack is in weeks. Any missing DNS TXT record that is missing, an expired WHOIS contact, or an engineer on leave is an expiry event.
Also Read: ACME’s Role in the Future of SSL/TLS Certificate Validity
Risks aren’t dramatic; they’re real. When browsers exhibit trust failures and API clients reject the handshake, availability is reduced. Security slips when an “easy” shortcut to install a “cert live” is used.
No evidence of inventory, no owner, no evidence of rotation on time – Compliance breaks! The certificate price shows up in the cost, as do fire-drill hours that are much greater than the number of certificates.
Outstanding is the use of automatic issuance while avoiding installation, reloading, and monitoring is still manual. That is the thesis of the rest of this post.
Five Things to do before March 2027
Develop an inventory rather than a Spreadsheet of Known Sites
Look for the TLS sites, APIs, mail, load balancing, Kubernetes, CDNs, and partner hostnames. Ensure inclusion of SANs, wildcards, and orphans that weren’t added to the CMDB.
Each Certificate should be given a Single Owner to be the Subject of a Single Renewal SLO
Having “security owns PKI” isn’t an owner. List who is authorised to start the service, change DNS, and how much warning time is required if/when the service fails to allow the cert replacement.
Retire posted Validation Methods which expire in March 2027
Reverse-lookup IP validation, Drop phone DV, email/fax/SMS/postal to IP Contact. Switch to HTTP-01, DNS-01, or another method that is still eligible after the deadline.
Automate Everything: request to validate, issue to install to reload, and verify
Not everything that emails a .crt should be considered automation. Run a live chain on one production-like host before March 2027.
Slow Change Control = Consider Certificate Renewal an exception
30–60-day CAB cycle cannot fit in an envelope of 100 days lifetime. Have automatic renewal pre-approved with them and a documented rollback.
200-Day vs 100-Day vs 47-Day TLS
Validity and DCV reuse shrink on different curves. That is what breaks operations.
| Dimension | 200-day TLS (now) | 100-day TLS (15 Mar 2027) | 47-day SSL (15 Mar 2029) |
| Max validity | 200 days | 100 days | 47 days |
| DCV reuse | 200 days | 100 days | 10 days |
| Renewals / cert / year | 2 | 4 | 8 |
| DCV events / year | 2 | 4 | Many (validation almost every issue) |
| Slack if a renewal fails | Weeks | Days to a couple of weeks | Days |
| Manual spreadsheet ops | Painful, still possible for small estates | High outage risk at scale | Operationally unrealistic |
| What “good” looks like | Inventory + reminders + some automation | Automated issue + install + alert | Continuous renewal + CLM visibility |
One hundred days is not halfway to 47. DCV reuse collapsing to 10 days in 2029 is a second problem. Buy a shorter cert and keep human DCV, and you fail twice.
How Enterprises Should Prepare?
Run a 90-day sequence. There is no need to wait for a charter before they learn.
- Days 1-30: inventory all public TLS endpoints. Distinguish public-trust from private PKI. Record what it is that can’t run ACME today: legacy appliances, air-gapped hosts, no port 80, no DNS API.
- Days 30-60: Select each automation pattern per estate (section 9). Test one non-critical public site and one site with high traffic. Prove: Install & service reload – not issuance.
- Days 60-90: Move to Wildcards, multi-SAN names, and prod/stage. Enable expiry and failure notifications. Record the break-glass reissue road.
Keep governance split. Public-trust certs are tied to the CA/B lifetimes. Internal PKI does not: You can blend them in so that you don’t know what will be coming up for the June 2027 expiration.
Also Read: Manual vs. Automated SSL Certificate Management: Why Automation is Must
How ACME makes 100-day TLS easier
ACME (Automated Certificate Management Environment) allows for communication between the client and the CA, validates the domain, downloads the certificate, and repeats this process at regular intervals; No CSR email chain.
That’s the m2m cycle that gives ACME the 100-day TLS. Validation and renewing is done on a Timer, rather than a Ticket.
HTTP-01 offers a token on port 80. Wildcards are looking for a path that corresponds to DNS-01’s writing of a TXT record. Typical blockers are closing port 80, forgetting DNS API tokens, split-horizon DNS, and a CAA record that identifies a different CA.
Also Read: How to Issue a Wildcard Certificate using ACME DNS Challenge & API Token?
ACME solves issuance. Still need to deploy, manage, multi-CA policy, and human alerts. This is typically one of the reasons why ACME is integrated under a CLM platform or under an installed agent as opposed to being a standalone solution.
Three Practical Ways to Automate SSL
| Path | Best fit | What it automates | Watch-outs |
| ACME (protocol + client) | Dev/platform teams, K8s, Linux fleets, anyone already on Certbot/acme.sh or CA ACME endpoints | Request, DCV, renew | You still own the client, DNS/HTTP challenge, install hooks |
| AutoInstall SSL | VPS / dedicated / cloud VMs (Apache, NGINX, IIS) that want one-command install + renew | CSR → validate → install → renew on the server | Tied to supported web servers and vendor workflow |
| CLM platforms | Enterprises with hundreds+ certs, mixed CAs, audit needs | Discovery, policy, issuance, renewal, revocation, reporting | Heavier rollout; worth it when inventory and owners are the real problem |
It is referred to by its protocol, ACME. Use when platform teams already have Linux, Kubernetes, or hookable web servers. The challenge, install hook, and the pager remain yours.
AutoInstall SSL is compatible with classic VMs. An agent copies, validates, installs, and renews the CSR on Apache, NGINX, or IIS. Do not stray from supported servers or supported vendor path/cycle.
The problem of hundreds of certificates, a mixture of CAs, missing owners, and auditors makes CLM platforms worth their price. They discover, policy-gate, issue, renew, and revoke; they report. This will be more of a spate to launch.
Almost every organisation will have more than one of these. ACME in the corner, AutoInstall on classic servers, CLM as the system of record.
Also Read: Setting Up SSL Auto-Renewal with Different ACME Clients: Step-by-Step Guide
Don’t Wait for 47-Day SSL to Force Your Hand
March 2027 is the wake-up call. Lock in 47-day certificates and 10-day DCV reuse in March, 2029. Then, after two more years, you have time to learn automation at an 8× renewals load, rather than a 4× load.
Teams can choose to use SSL automation offered by Certera, ranging from ACME-based issuance to AutoInstall SSL for server-side install and renewal, and CLM-style management, instead of taking a gamble on a single SSL protocol. Begin with the earliest certificates due to expire in June 2027. The first 100-day radius.
