The maximum validity period for publicly trusted TLS subscriber certificates was approximately 398 days before March 15, 2026. It is now 200 days, will fall to 100 days on March 15, 2027, and reaches 47 days on March 15, 2029. Shorter lifetimes improve certificate freshness, but they also make dependable renewal automation and expiration visibility increasingly important.
What is changing with TLS certificate validity?
The CA/Browser Forum Baseline Requirements establish maximum validity periods for publicly trusted TLS server certificates. The phased schedule applies to newly issued certificates based on their issuance date:
- 398 daysPrevious maximum validity
- 200 daysCurrent maximum validityCurrent phase
- 100 daysNext scheduled maximum
- 47 daysFinal scheduled maximum
This schedule is documented in the CA/Browser Forum Baseline Requirements. DigiCert also provides a readable overview of the move to 47-day TLS certificates.
The change concerns publicly trusted TLS certificates. The Baseline Requirements do not govern private PKI used only inside an organization when its root is not distributed by public application software suppliers. Even so, teams often monitor both public and internal certificates because either can cause operational problems when it expires unexpectedly.
Why shorter certificate lifetimes change the operational workload
If you manage websites, APIs, reverse proxies, NAS interfaces, customer environments, or self-hosted services, you are the person responsible for keeping those certificates healthy. The move from roughly annual certificates toward 47-day certificates creates more renewal events for every endpoint.
Shorter validity is not inherently a problem when issuance and renewal are automated correctly. The operational risk appears when a renewal job fails, a certificate is installed on the wrong service, an old certificate remains active, or an endpoint was never included in the automation workflow.
What a missed renewal can affect
- Browser trust warnings on public websites and administrative interfaces
- Unavailable services when clients reject an expired certificate
- Failed API calls and broken application integrations
- Emergency renewal work and avoidable downtime
- Support incidents that could have been handled during planned maintenance
Why manual tracking becomes harder
A spreadsheet, calendar event, or occasional browser check may appear adequate when certificates renew about once a year. As lifetimes shorten, those approaches must track more frequent changes across every domain, service, customer, and environment.
Static reminders also know when a certificate should renew, not necessarily which certificate an endpoint is presenting right now. A renewal can complete while deployment fails, leaving the old certificate active. Visibility into the live endpoint remains useful even when automation does the renewal work.
Automation and monitoring solve different parts of the problem. Automation requests and deploys certificates. Monitoring checks certificate health and provides early warning when expiration is approaching. CertStat is a monitoring tool; it does not issue or automatically renew certificates.
CertStat provides a simple Android early-warning view
CertStat is an Android SSL certificate expiry monitor for administrators, homelab users, developers, MSPs, and small businesses. It connects to the endpoints you configure, displays remaining validity and expiration details, and can provide local certificate expiration alerts based on your thresholds.
CertStat complements ACME clients, reverse proxies, certificate managers, and other automated renewal systems. It gives you another way to see which live endpoints are healthy and which need attention—without claiming to replace the systems that issue and deploy certificates.
Explore the certificate monitoring features or follow the CertStat getting-started guide to see the workflow.
A four-step certificate monitoring plan
Add important certificates to CertStat
Start with public websites, APIs, reverse proxies, remote-access services, and other endpoints where an expiration would have a visible impact.
Monitor validity and expiration dates
Review the certificate each endpoint is currently presenting, including remaining days, issuer, common name, and health status.
Receive alerts before expiration
Configure warning, critical, and red-alert thresholds that leave enough time to investigate a failed or incomplete renewal.
Renew before services are affected
Use your certificate authority, ACME client, hosting platform, or existing automation to renew and deploy the certificate, then verify the live endpoint presents it.
The goal: fewer certificate surprises
As maximum TLS certificate validity moves from 200 days to 100 days and eventually 47 days, renewal automation becomes increasingly important. Monitoring adds the visibility needed to catch exceptions when automation does not produce the expected result.
A clear expiration view helps you plan work before it becomes urgent, reduce the chance of certificate-related outages, and understand which endpoints need attention. It cannot guarantee that every renewal succeeds—but it can make missed renewals harder to overlook.
Monitor certificate expiration from Android.
Use CertStat alongside your existing renewal process to track validity and receive timely alerts.