Skip to content 
100-day TLS certificates become the public Web PKI maximum for certificates issued on or after March 15, 2027 and before March 15, 2029. The change does not mean every certificate suddenly expires on March 15, 2027. It means newly issued publicly trusted subscriber certificates in that period cannot exceed 100 days. For small businesses and IT teams, the urgent work is identifying where renewal and certificate installation are still manual, because the industry moves again to a 47-day maximum on March 15, 2029.
The Timeline Is Already in the Current Baseline Requirements
The CA/Browser Forum Baseline Requirements version 2.3.0, dated September 7, 2026, specify a phased reduction. Public TLS certificates issued from March 15, 2026 through March 14, 2027 are limited to 200 days. From March 15, 2027 through March 14, 2029, the maximum becomes 100 days. From March 15, 2029, it becomes 47 days.
The same schedule also tightens how long domain validation information can be reused. This is an issuance rule, not a mass expiration event for certificates issued earlier under the rules that applied to them.
Renewal and Deployment Are Two Different Automation Problems
Much of the industry discussion focuses on automatically obtaining a new certificate. That is only half the lifecycle. The renewed certificate also has to be installed on the correct server, load balancer, firewall, VPN gateway, appliance or application, then the service must actually present the new certificate to clients.
A May 2026 r/sysadmin thread about shorter lifetimes captured this distinction well. Administrators noted that ACME can automate issuance, while the harder work is often the integration that binds a renewed certificate to legacy services and safely reloads them. That is community experience, not a standards requirement, but it identifies the operational gap businesses should inventory now.
Build a Certificate Responsibility Table Before Buying Anything
| Service type | Typical renewal model | What still needs verification |
|---|---|---|
| Managed CDN or cloud edge | Provider managed | Domain validation remains valid and the certificate is attached to the live service |
| Cloud load balancer | Often provider managed | Certificate eligibility, DNS validation and correct resource association |
| Web server with ACME client | Client driven automatic renewal | Scheduled client runs, successful deployment and reload behavior |
| IIS or legacy application server | Varies | Whether renewal also updates bindings and service configuration |
| Firewall, VPN or appliance | Vendor specific | ACME or API support, import method and restart requirements |
| Imported certificate in a cloud service | Often customer managed | Who obtains and reimports the replacement |
This table prevents a common mistake. Because one cloud service renews certificates automatically, it does not follow that every certificate visible in the same account has the same lifecycle.
AWS Shows the Difference Between Managed and Customer Driven Renewal
AWS Certificate Manager provides managed renewal for eligible Amazon issued certificates. Its renewal documentation says eligibility depends on how the certificate was issued and used. Certificates associated with supported AWS services and properly validated can renew automatically, while imported certificates and some private certificate paths are not covered by the same managed lifecycle.
AWS now also supports ACME issuance for certain certificate workflows, but its documentation says the ACME client is responsible for renewal. Issued through AWS therefore does not always mean AWS will renew and deploy it automatically.
Let’s Encrypt Is Moving Faster Than the Minimum Schedule
Let’s Encrypt currently issues 90-day certificates by default, already below the 100-day maximum that arrives in 2027. Its published roadmap goes further. The default classic profile is scheduled to move to 64-day certificates in February 2027 and 45-day certificates in February 2028. An opt in 45-day TLS server profile is already available for early adopters.
Let’s Encrypt explains that shorter lifetimes reduce the window of exposure after key compromise or mis-issuance and push certificate management toward automation. Its 2026 rate limit guidance also says normal renewals are designed to remain workable as renewal frequency increases.
The Small Business Risk Is the Forgotten Certificate
A modern marketing website behind a managed CDN may need no new manual process. The risk is more likely to sit in a less visible system such as a VPN portal, NAS interface, remote management appliance, older IIS application, mail gateway, backup console or vendor product that requires manual certificate import.
Those systems may have been renewed once a year by one administrator who remembers where the certificate file goes. A 100-day maximum turns that memory based process into a recurring operational risk. A 47-day maximum makes it even less sustainable.
Use the Next Six Months as an Automation Audit
Before March 15, 2027, inventory every publicly trusted TLS certificate and identify its issuer, endpoint, renewal owner, validation method, installation method and monitoring. Then classify the lifecycle as fully managed, ACME automated, API automated or manual.
For every automated certificate, verify the last successful renewal and the certificate actually served by the endpoint. An ACME client can obtain a replacement while deployment fails. For every manual certificate, investigate whether the product supports ACME, an API or a managed certificate service. Where automation is impossible, shorten the monitoring interval and make ownership explicit.
This fits ITechTrove’s existing cloud security operations guidance. A security control is only reliable when the organization knows who owns its lifecycle and can detect failure before users do.
Monitor the Certificate Users Actually Receive
Do not treat renewal job succeeded as the final check. Monitor the external endpoint not. After date, issuer and chain. A renewed file sitting on disk does not help if the web server still presents the previous certificate because a binding was not updated or a reload failed.
For critical services, alert well before expiry and test the complete deployment path after configuration changes. The shorter the certificate lifetime, the less room there is for an unnoticed broken renewal job.
What Changes on March 15 2027
The headline is a 100-day maximum, but the operational consequence is broader. Certificate management moves from an occasional maintenance task toward continuous automation. Organizations that already use managed cloud certificates or reliable ACME workflows may notice little. Organizations that still copy certificate files by hand will feel the change immediately.
The best preparation is not purchasing certificates earlier. It is removing manual deployment steps and proving the monitoring path before the renewal cadence accelerates again.
FAQs
Will all TLS certificates expire on March 15 2027?
No. The rule applies to publicly trusted subscriber certificates issued on or after that date. Existing certificates follow the validity period under which they were issued.
How long can a TLS certificate last after March 15 2027?
The CA/Browser Forum Baseline Requirements set a maximum validity period of 100 days for certificates issued from March 15, 2027 through March 14, 2029.
Will Let’s Encrypt certificates become 100 days?
No. Let’s Encrypt already defaults to 90 days and plans shorter defaults with 64 days in February 2027 and 45 days in February 2028 according to its current roadmap.
What should businesses automate first?
Automate both issuance and deployment for certificates on systems that are still manually maintained. Then monitor the certificate actually served to users, not only the renewal job or certificate file.
