When are TLS certificates renewed, and how often after expiration?
Published: in Data analysis
When are TLS server certificates renewed, and how often does renewal happen only after expiration?
We have looked at Certificate Transparency data to try to find out.
Our final cohort included 316,576,332 publicly trusted TLS certificates that expired in May 2026. Of those, 3,875,280 certificates (1.2%) had a matching renewal issued in the first five days after expiration.
This post explains how we measured renewal timing and what we found, and it includes an interactive renewal timing chart.
Certificate Transparency data
Certificate Transparency (CT) is a public logging system for publicly trusted TLS certificates. It makes certificate issuance visible, so domain owners, security researchers, and others can monitor which certificates have been issued by publicly trusted certificate authorities (CAs).
CT was developed after a series of CA failures, including the 2011 DigiNotar compromise, in which attackers were able to issue hundreds of unauthorized certificates.
Major browsers now require publicly trusted TLS server certificates to be accompanied by proof that the certificate has been submitted to multiple recognized CT logs. This proof comes in the form of Signed Certificate Timestamps (SCTs). SCTs can be delivered in several ways, but they are most often embedded directly in the certificate by the issuing CA.
Data from CT logs is what makes it possible for us to do this analysis. Note, however, that the data only tells us that certificates were issued, not whether they were deployed.
How we measured renewal timing
We used data from Chrome-recognized Certificate Transparency (CT) logs.
We grouped certificates by their exact Subject Alternative Name (SAN) list. A later certificate with the same SAN list was treated as a renewal candidate only if it expired after the earlier certificate. Note that if a replacement certificate adds a SAN name, for example, then the expiring certificate will be counted as not having been renewed.
We primarily used the earliest CT log timestamp as the issuance time, since notBefore is allowed to be backdated by up
to 48 hours.
For each certificate in the final May 2026 cohort, we looked for the earliest matching renewal issued after the original certificate was issued and no later than five days after the original certificate expired.
See the Methodology section for the full filtering and matching rules.
Findings
3.8 million matching renewals were issued after expiration
Our final cohort contained 316,576,332 certificates that expired in May 2026. Of those, 3,875,280 certificates (1.2%) had a matching renewal issued in the first five days after expiration. Another 5,533,764 certificates (1.7%) had a matching renewal issued in the final three days before expiration.
The most common renewal time was about one month before expiration.
We did not identify a matching renewal within the five-day lookahead window for 87,646,879 certificates (27.7%). Many of these may have been renewed with a changed SAN list.
Renewals after expiration were more common for longer-lived certificates
Shorter-lived certificates are likely renewed automatically more often than longer-lived certificates, which should reduce the risk of late renewals.
That matches the data. Certificates valid for 360–398 days and 101–200 days were renewed after expiration much more often than certificates valid for 90–100 days.
0–7 days is the main exception. However, its high late-renewal rate is almost entirely due to one-day certificates issued by GlobalSign nv-sa for a single security product.
| Validity period | Renewed after expiration | Notes |
|---|---|---|
| 360–398 days | 6.0% (1,714,153) | |
| 101–200 days | 6.0% (766,110) | |
| 0–7 days | 3.7% (218,447) | The high late-renewal rate is almost entirely due to one-day certificates issued by GlobalSign nv-sa for a single security product. |
| 90–100 days | 0.4% (1,172,851) |
90-day certificates were by far the most common
Most certificates in the cohort were valid for 90–100 days, with 90-day certificates making up most of that group.
| Validity period | Share of cohort | Notes |
|---|---|---|
| 90–100 days | 84.6% | Mostly 90-day certificates |
| 360–398 days | 9.0% | |
| 101–200 days | 4.0% | |
| 0–7 days | 1.9% | |
| Other | 0.5% |
Related: Max TLS server cert validity drops to 47 days by 2029
Let's Encrypt issued over half of the cohort
The table below shows the largest issuers in the final cohort. We use the issuer organization names as recorded in the certificates, without normalization.
| Issuer | Share of cohort | Most common validity periods |
|---|---|---|
| Let's Encrypt | 52.6% | 90–100 days: 99.8% |
| Google Trust Services | 16.9% | 90–100 days: 98.5% |
| GoDaddy.com, Inc. | 7.8% | 360–398 days: 54.1%, 101–200 days: 23.6% |
| ZeroSSL | 7.4% | 90–100 days: >99.9% |
| Sectigo Limited | 4.3% | 90–100 days: 93.9% |
| DigiCert Inc | 3.9% | 360–398 days: 56.9%, 90–100 days: 40.4% |
| Amazon | 3.1% | 360–398 days: 56.7%, 0–7 days: 41.5% |
| Microsoft Corporation | 3.0% | 101–200 days: 71.2%, 90–100 days: 17.2% |
| Other | 1.0% |
Interactive renewal timing chart
The chart shows when matching renewals were issued relative to the expiring certificate’s expiration. Negative values mean the renewal was issued before expiration. Positive values mean it was issued after expiration. The leftmost bar groups renewals issued more than 100 days before expiration.
Certificates without a matching renewal in the five-day lookahead window are included in the summary above the chart, but are not shown in the chart.
The issuer filter uses issuer organization names as recorded in the certificate. It includes the top 20 values in the final cohort, plus Other issuers for all remaining values. Names are not normalized, so small naming differences may appear as separate issuers.
Ideas for future analysis
If you have ideas for how this analysis could be improved, or other interesting questions that could be explored using Certificate Transparency data, please email us at hello@certobserver.com.
Appendix: Methodology
Data source
Our data comes from the Certificate Transparency logs in Chrome’s CT Log Lists.
Deduplication
The same certificate can appear in the logs both as a precertificate and as a final certificate. We have deduplicated entries using
the issuer key and a normalized TBSCertificate representation that removes CT-specific differences.
Matching certificates by exact SAN list
We group certificates by their exact Subject Alternative Name (SAN) list. When a later certificate has the same SAN list, we treat it as a renewal candidate for the earlier certificate.
Issuance time
We primarily use the earliest CT log entry timestamp, rather than notBefore, as the certificate’s issuance time.
The reason for this is that CAs are allowed to set notBefore to any timestamp within 48 hours of the certificate
signing operation.
CA practices vary; for example, Let's Encrypt backdates it by one hour, while Sectigo backdates it to the most recent midnight in
UTC.
The exact logic we use is: greatest(notBefore, least(minSeenTimestamp, notBefore + interval '48 hours'))
Creating the cohort
We selected the certificates for the renewal analysis as follows.
- We started with 372,425,849 deduplicated certificates that expired in May 2026 (UTC), had at least one DNS SAN name, and were not issued by known test, staging, or CT testing intermediates.
- Within each exact SAN list group, we kept only certificates that extended coverage beyond all earlier certificates in that group. This removed 20,021,328 certificates (5.4%) that were fully covered by another certificate with the same SAN list.
- We then removed certificates where the next certificate with the same SAN list was issued less than one hour later. This removed another 35,828,189 certificates (10.2% of the remaining set). This step reduces repeated issuance that looks like renewal activity but is more likely caused by web server fleets where each server requests its own certificate.
The final cohort contains 316,576,332 expired certificates.
Analyzing the cohort
For each certificate in the final cohort, we searched the full data set for the earliest certificate that met all of these conditions:
- It had the exact same SAN list.
- It was issued after the cohort certificate was issued, but no later than five days after the cohort certificate expired.
- It expired after the cohort certificate expired.
We then calculated the time between that certificate’s issuance time and the cohort certificate’s expiration time. Negative values mean that the certificate was renewed before expiration. Positive values mean it was renewed after expiration. Missing values mean we did not observe a matching renewal within the five-day lookahead window.