- Publicly trusted TLS certificates issued now can last no more than 200 days; the limit drops to 100 days on March 15, 2027.
- Automate domain validation and issuance with ACME where your CA and platform support it, then automate installation and reload too.
- Probe every public endpoint from outside the platform and alert well before expiry.
Your certificate dashboard says “renewed.” The load balancer still serves the old certificate. Users will care about the second fact.
That gap matters more as certificate lifetimes shrink. Since March 15, 2026, the CA/Browser Forum has limited new publicly trusted TLS server certificates to 200 days. The maximum becomes 100 days on March 15, 2027, then 47 days in 2029.
Do not turn that schedule into a faster calendar reminder. Build one path that proves three different outcomes: the CA issued a certificate, the platform deployed it, and a real client can see it.
First, check whether the rule applies
The CA/Browser Forum schedule covers publicly trusted TLS server certificates. It is not a general expiry rule for private internal PKI, client certificates, email signing or code signing.
A managed CDN or hosting service may already handle public certificates for you. Confirm the boundary. Custom origins, VPNs, mail gateways, appliances and direct-to-origin hostnames can still sit outside that managed path.
Write down every hostname and the place where TLS ends. Add the certificate owner, CA, validation method, renewal client, deployment target and external check. The software support calendar offers a useful ownership pattern for products that hide inside operations.
The next limit arrives in March 2027
Certificates issued from March 15, 2027, must not exceed 100 days. Domain and IP address validation data also has a 100-day reuse limit from that date. In 2029, certificate validity falls to 47 days, while that validation reuse limit falls to 10 days.
A CA may issue a shorter certificate. Let’s Encrypt still uses 90 days by default and plans to reach a 45-day maximum by February 2028. Design for the certificate you receive, not the largest period a rule permits.
| State | What to record | Proof that matters |
|---|---|---|
| Issued | Order ID, names, serial, expiry | The CA returned the expected certificate |
| Deployed | Target, version, reload result | The platform accepted and activated it |
| Live | Hostname, port, observed serial, expiry | An outside TLS handshake sees the new certificate |
Use ACME for issuance, not as a success label
ACME automates certificate management. It is an IETF standard. A client can create an order, prove control of identifiers and obtain the certificate. The exact challenge depends on the CA and your setup.
That does not guarantee the certificate reached every server. Some clients install and reload a web server. Other setups only place files on disk. A hardware appliance or cloud load balancer may need a separate API call.
Choose one low-risk hostname first. Run the supported ACME client as a dedicated identity. Give it only the DNS, secret-store and deployment rights it needs. Keep private keys out of logs, tickets and AI coding sessions; the secrets guide explains common leak paths.
Let the CA suggest a renewal window when possible
ARI adds timing. ACME Renewal Information lets a CA suggest when a client should renew. RFC 9773 says this can reduce load spikes and support early renewal before a mass revocation.
ARI is helpful, but support varies by CA and client. Check both. Keep a safe local fallback based on the certificate’s real expiry, and never hard-code a date that assumes all future certificates have the same lifetime.
Run renewal checks at varied times. A single midnight job can create a load spike, and one missed run should not put the service near expiry.
Probe what users actually receive
After deployment, connect to each public hostname from outside the hosting control plane. Check the name, chain, serial number and notAfter value. Compare the result with the certificate that the CA issued.
Cover every edge that can terminate TLS. A regional load balancer, IPv6 route or legacy origin can keep serving an old certificate while the main check passes.
Set alerts from the observed live expiry, not only from an inventory database. Use at least two alert stages and make the earlier one leave time for a failed validation, a maintenance window and a rollback.
Run a recovery drill before calling it automated
- Force a safe renewal. Use the CA’s staging service or a documented dry path when available.
- Break one dependency. In a non-production test, remove a needed DNS permission or block the deployment step. Confirm the alert names the failed state.
- Restore access. Re-run the job and confirm it is safe to repeat.
- Inspect the live handshake. Verify that the expected serial and expiry appear at every endpoint.
- Record the owner. Make one person or team accountable for the alert and exception path.
These are test cases to run, not claims that TechWeb tested your certificate system. Back up configuration before changing a gateway; the restore-test workflow helps prove the copy is useful.
Vendor-controlled paths need proof. Ask for renewal, deployment and monitoring evidence. The vendor evidence checklist gives a practical starting point.
Frequently asked questions
Do the shorter limits affect existing certificates immediately?
No. The schedule applies by issue date. A certificate issued before a new limit keeps its stated validity unless it is replaced or revoked.
Does ACME deploy the certificate everywhere?
Not by itself. ACME automates certificate management, but installation and activation depend on the client, server, appliance or platform integration.
Should monitoring trust the CA dashboard?
No. Monitor the certificate served by each real endpoint. The CA record cannot prove that deployment and reload succeeded.
Does the 100-day rule cover private PKI?
Not as a CA/Browser Forum public-trust requirement. Your private PKI may use its own policy, product limits or compliance rules.
Sources
CA/Browser Forum: TLS Baseline Requirements · IETF RFC 8555: ACME · IETF RFC 9773: ACME Renewal Information · Let’s Encrypt: Certificate lifetime plans. Certificate policy and product support can change; verify the live documents before rollout.
More in this sectionTechnology →