SSL/TLS certificate statistics for the top 10,000 sites
In short
In November 2026 we opened one TLS connection to each of the top 10,000 websites and read the certificate it sent. Here is what they use, a few months into the 200-day limit and ahead of 47-day certificates.
The short version
Of the 8,860 sites that completed a handshake:
- 52.1% already use a certificate valid for 90 days or less, and 0.7% one of 47 days or less, the limit for public certificates issued from March 15, 2029.
- Let’s Encrypt issued 25.8% of the certificates, more than any other certificate authority.
- 99.7% of Let’s Encrypt certificates come from its new YE and YR intermediates, and 7 from older ones (E8, R3, R11, R12 and R13).
- 15% still carry the TLS client authentication extended key usage, which Chrome’s rules remove from public certificates issued from March 15, 2027.
- 97.5% served a complete, trusted chain for the name we asked for, judged against the Mozilla root store; 40 sent an incomplete chain; 52 sent an expired certificate; 155 sent a certificate for a different name.
Certificate lifetimes
A certificate’s lifetime is the time between its “not before” and “not after” dates. The median is 90 days and the mean 172.3. Since March 15, 2026, the Baseline Requirements let a public certificate authority issue certificates of at most 200 days. The chart counts every certificate a site sent, including self-signed and privately issued ones, which those rules don’t cover.
Who issues them
The issuer is the organization named in the certificate’s issuer field, so a brand that resells another authority’s certificates counts under the one that signed them.
Let’s Encrypt’s new intermediates
Let’s Encrypt signs certificates with intermediates, not its roots. It now issues from four intermediates under new roots, YE1 and YE2 (ECDSA) and YR1 and YR2 (RSA), and lists R10–R14 and E5–E9 as retired: still valid, no longer issuing (Let’s Encrypt’s chains page). Of its 2,282 certificates here, 99.7% come from the new ones.
Keys and TLS versions
40.3% of the certificates use an elliptic-curve (ECDSA) key, smaller and faster than RSA at the same strength. 85.9% of the connections used TLS 1.3; the rest used TLS 1.2. Our client offers only TLS 1.2 and 1.3, so a site that speaks nothing newer than TLS 1.1 shows up as a failed handshake.
Expiry and chain problems
Days left are counted from the moment of each handshake. 4.8% had not expired and had fewer than 30 days left. With automation that is routine: Certbot and Caddy renew when a third of the lifetime remains, about 30 days for a 90-day certificate.
97.5% served a complete, trusted chain for the name we asked for, judged against the Mozilla root store. The problems we found, by type; a site can have more than one, since the name is checked apart from the chain.
| Problem | Sites | Share |
|---|---|---|
| Incomplete chain | 40 | 0.5% |
| Expired certificate | 52 | 0.6% |
| Self-signed or unknown root | 18 | 0.2% |
| Name does not match | 155 | 1.7% |
An incomplete chain is the easiest of these to miss: browsers often fill the gap themselves, while curl, Node.js, Python and most API clients fail with “unable to get local issuer certificate”. How to read and fix chain errors.
What it means for the coming changes
The CA/Browser Forum’s Baseline Requirements cap a public certificate at 200 days since March 15, 2026, 100 days from March 15, 2027 and 47 days from March 15, 2029 (the schedule and its sources). 53.1% of these sites already use certificates of 100 days or less, inside the limit that starts on March 15, 2027, and only 0.7% are at 47 days or less today.
Let’s Encrypt moves its default certificates from 90 to 64 days on February 10, 2027 (what changes and what to check). Anything that renews on a fixed 60-day timer will then renew 4 days before expiry instead of 30, so most of the 25.8% of sites on Let’s Encrypt should renew by the time left on the certificate rather than on a calendar, as ACME clients that support renewal information (ARI) do.
Chrome’s rules leave client authentication out of public certificates issued from March 15, 2027, and 15% of these certificates still list it. That only matters where a public certificate is also used to log in to another server, such as XMPP servers connecting to each other (what breaks, and what to use instead).
How we measured
- The list: the top 10,000 domains of the Majestic Million by Majestic, the domains with the most referring subnets, retrieved on November 2, 2026. Majestic publishes it under CC BY 3.0; we used only its top 10,000.
- One handshake per site, from one server, on November 2, 2026: a TLS connection to port 443 of the domain exactly as listed, with the domain as the server name (SNI). No retry on
www., no HTTP request and no redirects followed, so a site that only answers on itswww.name counts as a failure. - The client: Node.js 22.22.1 (OpenSSL 3.5.5), offering TLS 1.2 and 1.3, and the same checker as our SSL certificate checker. Trust is judged against the Node.js bundled Mozilla CA store, without checking revocation; browsers apply their own root stores and rules, so a browser can decide differently. Private and reserved addresses are never contacted.
- What counts: percentages are of the 8,860 sites that completed a handshake, worked out from the counts and rounded once: to one decimal in the text and tables, to up to two in the charts. Lifetimes are rounded to whole days. A site that did not answer within 8 seconds, or failed for any reason below, is a failure and is left out of every other figure.
- What we publish: only the totals on this page, never the result for an individual site.
| Reason | Sites | Share of attempts |
|---|---|---|
| The name has no IPv4 or IPv6 address | 507 | 5.1% |
| No answer within the time limit | 305 | 3.1% |
| The DNS lookup failed | 217 | 2.2% |
| The TLS handshake failed | 52 | 0.5% |
| The connection was closed or reset | 27 | 0.3% |
| The name does not exist in DNS | 15 | 0.2% |
| Only private or reserved addresses | 12 | 0.1% |
| The network was unreachable | 5 | under 0.1% |
Download and cite
The totals behind every figure are one JSON file, the survey of November 2, 2026: certificate-survey-2026-11-02.json. We keep it at that address, unchanged. Shares are of the 8,860 completed handshakes, with two exceptions: failures are shares of all 10,000 attempts, and Let’s Encrypt’s intermediates, new and older, are shares of its own 2,282 certificates.
We plan to run the survey again each week. Each run gets a file of its own, named by its date, and never replaces an earlier one; this page and certificate-survey-latest.json move on to the newest. If you use the numbers, please cite the dated file, which keeps them after this page has moved on:
Boring Utils. TLS certificate survey of the top 10,000 websites, November 2, 2026 [dataset]. https://boringutils.com/data/certificate-survey-2026-11-02.json (report: https://boringutils.com/reports/ssl-certificate-statistics) Sources
- The Majestic Million, Majestic, retrieved November 2026: the list of sites, CC BY 3.0.
- Ballot SC-081v3, CA/Browser Forum, April 11, 2025: the 200, 100 and 47-day schedule.
- Chains of Trust, Let’s Encrypt, last updated July 8, 2026: the active and retired intermediates.
- 64-day certificates, Let’s Encrypt, October 7, 2026: the February 10, 2027 date.
- Chrome Root Program Policy, version 1.8, Google: server authentication only from March 15, 2027.