On this page · 10 sections
- What changes on 15 March 2027
- Why 100 days is a step change: the renewal arithmetic
- Let's Encrypt moves first, on 10 February 2027
- The validation and CAA changes inside the same rulebook
- eMudhra: the India angle and the case for a second CA
- The 90-day automation checklist
- What the 100-day rule does not cover
- India and global notes
- How eCorpIT can help
- References
Summary. From 15 March 2027, no publicly trusted certificate authority may issue a TLS server certificate valid for more than 100 days. That is the second step of CA/Browser Forum ballot SC-081v3, adopted on 11 April 2025 with 25 CA votes in favour, none against, and yes votes from Apple, Google, Microsoft and Mozilla. The cap in force since 15 March 2026 is 200 days, and the final cap is 47 days from 15 March 2029. The same March 2027 date cuts domain-validation reuse from 200 to 100 days, requires every CA to process the CAA accounturi and validationmethods parameters, and ends phone validation through DNS TXT or CAA contacts. A one-year subscription therefore means at least four certificates a year, and at least eight by 2029. Let's Encrypt users see change first, because its default drops from 90 to 64 days on 10 February 2027. The October 2026 compromise of eight eMudhra intermediate keys, and Chrome's removal of the emSign ECC Root CA - G3 root, showed why a second CA belongs in every plan. Counting from 1 November 2026, 134 days remain. Inventory first, then automate with ACME and ACME Renewal Information (ARI).
About this article. For the IT, security and platform teams that own public TLS certificates. We read the TLS Baseline Requirements version 2.3.1 (dated 4 October 2026) and ballots SC-081v3, SC-088v3 and SC-090, plus publications from Let's Encrypt, Google, Mozilla, CERT-In and eMudhra, and checked them on 1 November 2026. This is not legal advice, and CAs and root programmes change policy often, so re-check before you commit. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
This is the planning and inventory guide. For a tool-by-tool view of certbot, acme.sh, cert-manager, Caddy, Traefik, win-acme and Posh-ACME, see our ACME client comparison. For the February change, see Let's Encrypt's move to 64-day certificates.
What changes on 15 March 2027
Ballot SC-081v3 rewrote two sections of the TLS Baseline Requirements (BRs): section 6.3.2, which sets the maximum validity of subscriber certificates, and section 4.2.1, which sets how long a CA may reuse validation data. Clint Wilson of Apple proposed it, with endorsements from Sectigo, Google Chrome and Mozilla. Voting closed on 11 April 2025. Indian CA eMudhra was among the 25 CAs that voted yes; Entrust, IdenTrust, Japan Registry Services, SECOM and TWCA abstained. The change entered the BRs as version 2.1.5, effective 16 May 2025.
The current BR relevant-dates table and sections 4.2.1 and 6.3.2 set out the schedule below. Each date applies to certificates issued on or after it.
| Issued on or after | Max certificate validity | Max reuse of domain or IP validation | Other BR changes on the same date |
|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 398 days | Organisation identity data reusable for 825 days |
| 15 Mar 2026 (in force) | 200 days | 200 days | Identity data reuse cut to 398 days; DNSSEC validation required for DCV and CAA lookups; IP address method 3.2.2.4.8 ends |
| 15 Mar 2027 | 100 days | 100 days | CAs must process CAA accounturi and validationmethods; phone DCV via DNS TXT or CAA contacts (3.2.2.4.16, 3.2.2.4.17) ends; reverse address lookup for IPs ends |
| 15 Mar 2028 | 100 days | 100 days | Email to constructed addresses such as admin@ or webmaster@, and email to CAA or DNS TXT contacts (3.2.2.4.4, .13, .14), end |
| 15 Mar 2029 | 47 days | 10 days | Final SC-081 step |
Three details matter for planning.
First, the cap applies at issuance, not to certificates already in use. A 200-day certificate issued on 14 March 2027 stays valid until about 30 September 2027. Some teams will renew everything in early March to buy those months. That is a reasonable bridge, but it only moves the problem to the autumn.
Second, the rule covers publicly trusted TLS server certificates generally: DV, OV, EV and wildcard alike. There is no regional exemption for India, the EU or anywhere else.
Third, 100 days is a ceiling. The BRs also advise CAs to stay at 99 days or less, because any fraction of a day counts as a full day. CAs may issue shorter certificates, and some already do.
Why 100 days is a step change: the renewal arithmetic
Most teams that still renew by hand got away with it because a 398-day certificate needed attention roughly once a year. The table shows what happens as the cap falls. It assumes renewal at two-thirds of the certificate's life, which is Let's Encrypt's published guidance, and an illustrative 45 minutes of staff time per manual renewal (CSR, approval, validation, installation and a check). The 45 minutes is our assumption, so swap in your own.
| Max validity | Renew every (2/3 of life) | Renewals per name per year | 300 manual certificates: renewals a year | Staff hours a year at 45 minutes each |
|---|---|---|---|---|
| 398 days | ~265 days | 1.4 | 413 | 310 |
| 200 days | ~133 days | 2.7 | 821 | 616 |
| 100 days | ~67 days | 5.5 | 1,643 | 1,232 |
| 47 days | ~31 days | 11.6 | 3,495 | 2,621 |
The arithmetic: 365 ÷ (100 × 2/3) = 5.475 renewals per name per year; 300 × 5.475 ≈ 1,643 renewals; 1,643 × 0.75 hours ≈ 1,232 hours. At roughly 1,800 working hours per person per year, that is about 0.7 of a full-time role at 100 days and about 1.5 roles at 47 days. The bigger cost is the outage when one renewal slips on a payment page or a partner API.
Commercial CAs still sell multi-year subscriptions, but under a 100-day cap each subscription year needs at least four issued certificates (365 ÷ 100 = 3.65). The purchasing model can stay the same; the installation work cannot.
Let's Encrypt moves first, on 10 February 2027
Let's Encrypt already issues certificates well under 100 days, so the March cap changes nothing for it directly. Its own schedule is the one to watch. On 10 February 2027 its default classic ACME profile switches from 90-day to 64-day certificates and cuts authorisation reuse from 30 days to 10, and it expects the last 90-day certificate to expire on 11 May 2027. Staging switched on 14 October 2026. On 16 February 2028 the default falls to 45 days with seven-hour reuse. The opt-in tlsserver profile has issued 45-day certificates since 13 May 2026, and shortlived issues certificates valid for 160 hours.
The failure mode is hard-coded timing. Let's Encrypt suggests searching cron jobs, wrapper scripts and runbooks for numbers such as 83, 80 or 60, and renewing at about two-thirds of the lifetime or with ARI. It says rate limits are unaffected. It also ended its expiry reminder emails on 4 June 2025, so monitoring is now your job.
The validation and CAA changes inside the same rulebook
The validation changes that land alongside the cap cause more surprises.
Domain validation reuse falls to 100 days. Enterprises that pre-validate domains with a commercial CA once a year will find that validations older than 100 days cannot support issuance after 15 March 2027, and from 2029 the limit is 10 days. Plan for automated DNS or HTTP validation rather than an annual approval cycle.
CAA account and method binding becomes universal. RFC 8657 lets a domain owner add accounturi (only this ACME account may issue) and validationmethods (only these challenge types) to a CAA record. Let's Encrypt already documents both. From 15 March 2027 the BRs require every CA to process them, under ballot SC-098, and a CA that identifies subscribers some other way must define its accounturi format in its CP or CPS. This is a strong control against mis-issuance. It is also a trap: if you bind a zone to one ACME account and then rebuild a Kubernetes cluster that generates a new account key, issuance fails until you update the record, unless your CA maps sub-accounts to a parent account, as the BRs now permit.
; Two authorised CAs, the primary bound to one ACME account and DNS-01 only
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890; validationmethods=dns-01"
example.com. 3600 IN CAA 0 issue "sectigo.com"
example.com. 3600 IN CAA 0 iodef "mailto:pki-alerts@example.com"
Email and phone validation is on its way out. Ballot SC-090 removes phone validation via DNS TXT and CAA contacts on 15 March 2027, and the email methods, including the familiar email to admin@ or webmaster@, on 15 March 2028. Teams that approve domain validation by clicking a link in an email have about 16 months to move to DNS or HTTP methods.
DNSSEC errors now block issuance. Since 15 March 2026 CAs must validate DNSSEC for validation and CAA lookups, and a SERVFAIL is not treated as permission to issue. A zone with broken DNSSEC signatures will fail renewals.
A persistent DNS method exists, but check who runs it. Ballot SC-088v3 added method 3.2.2.4.22, effective 10 November 2025. You publish a standing _validation-persist TXT record naming the CA and your ACME account, and renewals no longer need fresh DNS changes. The CA still re-checks the record, with a 10-day reuse limit. Availability lags the rule. Google Trust Services went live on 28 September 2026 using IETF draft 01, and warns that early adopters may need to update records. Let's Encrypt targeted production for Q2 2026, then a developer there said on 25 June 2026 that deployment would wait for an open draft issue. That issue closed on 23 September 2026, and we found no production date on 1 November 2026. It suits appliances, multi-tenant platforms and teams that do not want DNS API keys spread across servers, once your CA and client both support it.
eMudhra: the India angle and the case for a second CA
On Saturday 17 October 2026, at 18:05 UTC, the Chrome Root Program received a researcher's report that the private keys of eight eMudhra subordinate CA certificates had been generated with insufficient randomness. Chrome blocked the affected intermediates through a CRLSet update by 19:45 UTC, and said no TLS certificate chaining to the six TLS intermediates had been logged to Certificate Transparency before the block. Mozilla pushed a OneCRL block to Firefox by 22:59 UTC. CERT-In says the keys could be recovered almost instantly from the public keys.
The root-level fallout is what affected site owners. Mozilla announced removal of emSign ECC Root CA - G3 through NSS 3.131.1 on 20 October. Google removed the same root from the Chrome Root Store, with the change expected to reach devices on 27 October 2026, and told operators with certificates chaining to it to install a new certificate from another hierarchy immediately. Google also said it is reviewing the continued inclusion of eMudhra's remaining CA certificates.
eMudhra's statement page, last updated 30 October, says the roughly 30,800 certificates under the affected G3 hierarchies belong to one client ecosystem in the United States, now using its G1 RSA root as a temporary pathway. It describes a voluntary wind-down of its publicly trusted TLS services, says most remaining TLS customers have already moved to other providers at no charge, offers Sectigo-issued certificates as an alternative, and on 30 October named KPMG as independent reviewer. It also states that its Indian digital signature certificate (DSC), eSign and enterprise products run on separate infrastructure and are unaffected.
India's CERT-In issued advisory CIAD-2026-0050 on 21 October. It confirms that DSC and eSign services regulated by the Controller of Certifying Authorities are not affected, and tells administrators to replace certificates chaining to emSign ECC Root CA - G3, update trust stores, and review applications, language runtimes, container images and appliances that carry their own CA bundles.
Four lessons apply to every Indian enterprise, whichever CA it uses:
- Automation is what lets you switch CAs quickly. Google's instruction was to replace certificates immediately. Teams with ACME automation can point their client at another CA and redeploy; teams with spreadsheets cannot.
- Authorise two CAs in CAA and keep a tested account with the second one, so a distrust event becomes a configuration change.
- Patch trust stores, not only browsers. The Hacker News reported fixes across Go, Node.js, Python certifi, Debian, Ubuntu and Red Hat, and noted that many non-browser programs do not check revocation data and keep trusting a chain until their code or root bundle changes.
- Keep Indian DSC and eSign separate in your thinking. They sit under India's CCA framework, not the browser root programmes, and the 100-day rule does not touch them.
The 90-day automation checklist
The plan below fits between now and the March deadline, with slack for change freezes. It assumes a mixed estate of Linux, Windows, Kubernetes, cloud load balancers and a few appliances.
Weeks 1 and 2: owner and policy.
- Name one owner for public TLS certificates, with a deputy.
- Set the rule: no manually renewed public certificate after 15 March 2027 unless it has a written exception and an expiry date.
- Choose a primary and a secondary CA, and confirm both support ACME. The acme.sh and win-acme documentation list Let's Encrypt, ZeroSSL, Google, SSL.com, DigiCert and Sectigo among compatible services. Some directories, including Sectigo's and Google's, require External Account Binding, so set up the account early.
Weeks 1 to 3: inventory. Use more than one source, because each misses something.
| Where certificates hide | How to find them | Usual fix |
|---|---|---|
| Public websites and APIs | Certificate Transparency search for each domain; external scan of ports 443 and 8443 | ACME client on the host or a reverse proxy |
| Cloud load balancers and CDNs | Your cloud provider's certificate inventory API or console | Provider-managed certificates the provider renews |
| Kubernetes Ingress and Gateway | kubectl get certificates -A and Secrets of type kubernetes.io/tls | cert-manager |
| Windows: IIS, Exchange, RD Gateway | Certificate store exports and IIS bindings | win-acme or Posh-ACME with deploy scripts |
| Appliances: firewalls, VPNs, NAS, printers | Internal port scans and vendor consoles | Vendor ACME or API support, or terminate TLS on a proxy in front |
| Java keystores, partner mTLS, pinned mobile apps | Code and config search for .jks, .p12 and pinning rules | Automate keystore import; pin to a CA set, never a leaf |
# 1. Every certificate CT logs have seen for a domain and its subdomains
# (crt.sh is often overloaded: -f makes an error page fail cleanly, so retry)
curl -fsS "https://crt.sh/?q=%25.example.com&output=json" \
| jq -r '.[] | [.not_after, .issuer_name, .name_value] | @tsv' | sort -u
# 2. Expiry date and issuer of what an endpoint actually serves
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
| openssl x509 -noout -enddate -issuer
# 3. Hard-coded renewal intervals that break with shorter lifetimes
grep -rnE '\b(83|80|60)\b' /etc/cron* /etc/systemd/system /opt/scripts 2>/dev/null
Weeks 3 to 5: classify every endpoint into one of four groups: ACME-native (Caddy, Traefik, cert-manager), scriptable with an ACME client and a deploy hook (certbot, acme.sh, win-acme, Posh-ACME), provider-managed (cloud load balancers and CDNs), or manual-only. The manual-only group is your risk register. Each item needs a replacement, a proxy in front, or a vendor API by March. Windows Server 2016 hosts may be easiest to fix inside their end-of-support migration.
Weeks 5 to 10: automate.
- Pick a validation method per zone: HTTP-01 for simple web servers, and DNS-01 with narrowly scoped API tokens or CNAME delegation of
_acme-challengefor wildcards and internal hosts.
- Turn on ARI wherever the client supports it, so the CA can tell your client when to renew, including early renewal before a mass revocation.
- Where ARI is not available, renew at two-thirds of the lifetime, never at a fixed number of days.
- Wire deploy hooks that reload the web server, push to the load balancer or update the keystore, then verify the served certificate changed.
Weeks 8 to 12: harden.
- Publish CAA records naming both CAs, and add
accounturibinding on your most sensitive zones once account keys are stable.
- Monitor Certificate Transparency for your domains so you see unexpected issuance.
- Alert on expiry from outside your network at 14, 7 and 3 days remaining.
Week 12 onward: rehearse.
- Point one non-critical service at Let's Encrypt's 160-hour
shortlivedprofile in staging. A six-day certificate flushes out timing bugs in a week rather than a quarter.
- Run a CA failover drill: switch one service to the secondary CA and back.
- Finish before 10 February 2027 if you use Let's Encrypt, and before 15 March 2027 for everything else.
What the 100-day rule does not cover
The BRs govern publicly trusted TLS server certificates only. Certificates from your own internal CA, such as Active Directory Certificate Services or a private ACME server, are outside their scope, and S/MIME and code-signing certificates have separate rulebooks. Certificates issued before 15 March 2027 keep their original validity. And the rule says nothing about price: CAs set their own commercial terms.
India and global notes
The rule is global, so an Indian bank, a US SaaS company and an EU retailer face the same 15 March 2027 date. What differs is exposure. Indian organisations that bought emSign certificates are being moved to other providers because eMudhra is winding down public TLS, and CERT-In's advisory addresses government departments, enterprises, ISPs and software vendors among its audience. For teams handling personal data under India's DPDP Act, an expired certificate is usually an outage rather than a breach. A mis-issued or compromised certificate is a security event, which is one more reason to pair automation with CAA and CT monitoring. Our DPDP Act engineering playbook covers the wider security-safeguard duties.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can run certificate discovery, ACME automation with deploy hooks, CAA and CT monitoring, and CA failover drills. Talk to us at /contact-us/.
Last updated: 1 November 2026.
