What Is SSL Certificate Monitoring?
Checking expiry, chain validity and hostname coverage on TLS certificates. Maximum lifetimes dropped to 200 days in March 2026.
SSL certificate monitoring is the automated checking of TLS certificates for approaching expiry, chain validity, hostname coverage and revocation status, so that a certificate problem is caught before visitors encounter it.
It has become considerably more important in 2026 because certificate lifetimes are shrinking on a fixed schedule, and renewal processes designed around an annual cycle no longer fit.
What changed on 15 March 2026
The CA/Browser Forum approved Ballot SC-081v3 in April 2025, proposed by Apple and sponsored by Sectigo. It phases the maximum lifetime of publicly trusted TLS certificates down from 398 days to 47.
The first step took effect on 15 March 2026, capping new certificates at 200 days. The vote passed with certificate authorities in favour 25 to nil with five abstentions, and all four major browser vendors voting in favour.
| Effective date | Max certificate lifetime | Max domain validation reuse |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
The reuse column is the part most teams underestimate. From 2029 domain control validation must be repeated every 10 days, which means any renewal process involving a human approving a DNS change stops being viable.
Why expiry is only part of the check
Expiry is the most common failure and the easiest to catch, but three others break sites just as thoroughly and are harder to notice.
An incomplete chain is the classic. A server that omits the intermediate certificate will work perfectly in most desktop browsers, which cache intermediates, and fail in mobile apps, curl and server-to-server calls that do not. The site looks fine to the person who deployed it.
Hostname coverage is the second. A certificate valid for example.com but not www.example.com, or a wildcard that does not cover a second-level subdomain, produces a name mismatch error that is indistinguishable to a visitor from a security warning.
The third is simply the wrong certificate being served, which happens on load balancers and CDNs where one node did not pick up the renewal. Checking from a single location can miss it entirely.
The discovery problem
The certificate that causes an outage is rarely the one on the main website. It is the internal API, the staging environment promoted to production, the legacy subdomain, or the appliance someone configured in 2021.
Automation via ACME covers what it is pointed at. It does not cover the endpoints nobody remembered, which is why an inventory pass is worth doing before evaluating any monitoring tool.
A note on how the check is performed
Certificate expiry does not require a separate probe. The expiry date is presented during the TLS handshake, so any monitor already making an HTTPS request can read it as a by-product of the connection it was making anyway.
That is worth knowing because it means certificate checking is nearly free to add wherever uptime checking already exists, and there is little reason for a tool to treat it as a premium feature.
Related concepts
Certificates are one case of credential expiry monitoring. The registration behind the hostname is covered separately in domain expiry monitoring.