Certificate Lifetime Checker and 2027 Renewals

How the lifetime checker reads Certificate Transparency history, checks each certificate against the SC-081 limits, and flags renewal schedules that will break.

Two lifetime changes land five weeks apart in early 2027. CA/Browser Forum Ballot SC-081 set the schedule for every public CA: 200 days from March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029. Separately, Let’s Encrypt announced that certificates it issues on or after February 10, 2027 will last 64 days by default.

Neither change breaks a client that renews automatically and asks the CA when to renew. What breaks is the renewal rule someone wrote years ago as a fixed number of days. The checker finds those rules from the outside, using only public log data, so you can run it against hosts you don’t administer yourself.

Step 1: read the history

Every publicly trusted certificate is logged to Certificate Transparency before browsers accept it, under the framework in RFC 9162. The checker asks CertIndex, an index of those logs, for up to 200 certificates that name the exact host you typed.

CAs log a precertificate first and often log the final certificate too. Both carry the same issuer, validity dates and names, so the checker merges each pair and counts one certificate. Matching is by exact name. If your host is served by a wildcard such as *.example.com, check the parent name as well.

Step 2: check each lifetime against its limit

Lifetime is the time from notBefore to notAfter. The limit that applies depends on the issue date, not today’s date. A certificate issued in December 2025 could last 398 days, and it is still valid today. The table shows the limit beside every certificate so the comparison is plain.

The checker allows one day of slack, because validity includes the final second and some CAs round to the day. Anything longer than that is flagged as a warning, not a confirmed problem. Confirm the dates in the certificate itself before you report it. Linters already enforce the schedule at issuance. For example, zlint added SC-081 checks so a CA’s pre-issuance linting rejects overlong certificates. When we measured 349 certificates issued since the 200-day cap, none ran past 199 days.

The more useful finding for most hosts is the next one. If the current certificate is a 397-day certificate issued before March 15, 2026, its replacement can last at most 200 days. The checker says so and estimates how many more renewals a year that means. When we pulled histories on October 22, pypi.org was in exactly that position.

Step 3: measure renewal timing

Certificates with the same issuer and the same set of names form a renewal series. For each certificate replaced before it expired, the checker records how many days it had left when the replacement’s validity began. The median of those values is your observed renewal habit, shown in days and as a share of the lifetime.

Let’s Encrypt’s integration guide recommends checking ACME Renewal Info (ARI) at least twice a day and, as a backstop, renewing when a third of the lifetime is left. ARI is defined in RFC 9773 and lets the CA suggest a renewal window for each certificate. For a 90-day certificate the backstop is 30 days. For a 64-day certificate it is about 21 days.

The checker then compares your habit with the next change:

• Let’s Encrypt, renewing with about 30 days left. Fine. A fixed 30-day rule renews 34 days into a 64-day certificate, earlier than needed but safe.
• Let’s Encrypt, renewing with about 60 days left. Warning. If that is a fixed rule, a 64-day certificate renews four days after issuance. The Let’s Encrypt announcement tells operators to search cron jobs and runbooks for values like 83, 80 or 60.
• Commercial CA, renewing with 65 days left on a 108-day certificate. Warning. Under the 100-day limit, that rule fires 35 days after each issuance.

In our renewal timing chart, 17 of 28 developer domains renewed Let’s Encrypt certificates at about 30 days left, and five renewed at about 60. The data can’t tell a fixed rule from the one-third guidance, and the checker can’t either. It reports what happened and leaves the cause to you.

Step 4: look for coverage gaps

Sorted by issue date, the certificates should overlap. A stretch where none of them was valid is a coverage gap. The checker reports gaps in the last 400 days with their start, end and length.

A gap does not always mean an outage. The host may have used a wildcard or a certificate for a different name during that time, or the index may be missing an entry while it loads older history. When none of those explain it, clients saw an expired certificate. That is the failure the ACME renewal post-mortem on this site describes.

Step 5: read the parallel issuance note

Some series contain certificates for the same names issued days apart while the previous one was still new. The checker counts any replacement that arrives in the first fifth of a certificate’s life as parallel issuance and leaves it out of the renewal timing. It usually means each server, region or CDN edge requests its own certificate.

That isn’t wrong, but it matters as lifetimes shrink. Each copy is another private key to protect, and each request outside ARI counts toward Let’s Encrypt’s rate limits, including five certificates per exact set of names every seven days. Halving lifetimes doubles that traffic.

Limits

The checker sees only what is logged and indexed. A large estate may have more than 200 certificates for one name, and the response says when the history is a lower bound. It cannot see which certificate a server presents right now. Use the TLS inspector for that, and the CT lookup for the full list of entries. Renewal timing needs at least one completed renewal, so a brand-new host shows lifetimes but no timing.

Read next

• The week 42 recap charts lifetimes since the 200-day cap.
• The week 43 recap charts when developer domains renew.
• The CAA record checker confirms your CAA record still allows the CA that renews for you.

Tags: #tls, #certificate-transparency, #acme, #lets-encrypt, #renewal