SSL/TLS certificate statistics for the top 10,000 sites

The short version

Of the 8,911 sites that completed a handshake:

• 52.3% already use a certificate valid for 90 days or less, and 0.6% one of 47 days or less, the limit every public certificate must meet from March 15, 2029.
• Let’s Encrypt issued 25.2% of the certificates, level with Google Trust Services (2,248 certificates to 2,244).
• 99.6% of Let’s Encrypt certificates come from its new YE and YR intermediates. The rest were issued before the switch, by intermediates it has retired, and will move over as they renew.
• 15.6% still carry the TLS client authentication extended key usage, which Chrome’s rules remove from public certificates issued from March 15, 2027.
• 97.4% served a certificate that browsers and other clients accept; 42 sent an incomplete chain; 50 sent an expired certificate; 159 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 175.8. Anything over 200 days was issued before that limit took effect on March 15, 2026, and its next renewal will be shorter.

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,244 certificates here, 99.6% come from the new ones.

Keys and TLS versions

40.8% of the certificates use an elliptic-curve (ECDSA) key, smaller and faster than RSA at the same strength. 85.5% 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.6% 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.4% 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.

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.3% of these sites already use certificates of 100 days or less, inside the limit that starts on March 15, 2027. The other 46.7% will get a shorter certificate at their first renewal after that date, and only 0.6% 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.2% 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.

The 15.6% of certificates that still list client authentication will lose it as they renew. 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 October 20, 2026. Majestic publishes it under CC BY 3.0; we used only its top 10,000.
• One handshake per site, from one server, on October 20, 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 its www. 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. Private and reserved addresses are never contacted.
• What counts: percentages are of the 8,911 sites that completed a handshake. 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.

Download and cite

The totals behind every figure are one JSON file: certificate-survey-2026-10.json. We plan to run the survey again each week and keep each month’s file at its own address. If you use the numbers, please cite and link this page:

Boring Utils, TLS certificate survey, October 2026. https://boringutils.com/reports/ssl-certificate-statistics

Sources

• The Majestic Million, Majestic, retrieved October 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.