The State of Signatures on the WebAugust 2026

Algorithms

ECDSA vs RSA: who signs the web

Every certificate here carries exactly one leaf key, and that key decides which algorithm verifies the site on every new connection.

RSA wins, and it is not close: 61.6% of the leaf certificates we collected carry an RSA key against 38.4% for ECDSA. There is no third option in this sample — not one Ed25519 certificate, because no publicly trusted CA issues them for TLS.

The interesting part is the lack of variety inside each camp. RSA-2048 alone accounts for 60.2% of everything, ECDSA P-256 for 37.8%: two key types cover 98% of the web's busiest sites. Nothing in the sample used a key below the accepted minimum — 0 certificates with RSA under 2048 bits.

Why does RSA still lead when ECDSA P-256 offers the same security level in a key that is roughly an eighth of the size? Because almost nobody picks the algorithm by hand — the certificate authority's default picks it. Split the same domains by who issued their certificate and the pattern is obvious:

Google Trust Services issues 39.3% of the certificates in this sample and hands out elliptic-curve keys by default — 96 of its 137 are ECDSA. Amazon, on the other hand, issued 37 certificates here and every single one is RSA, because that is what its console offers first. The ECDSA-versus-RSA split on the web is, to a first approximation, a map of which CA a site happened to use.

The 47-day countdown

Certificate lifetimes are collapsing — but not far enough

The CA/Browser Forum has put public certificate lifetimes on a schedule (ballot SC-081): 200 days from March 2026, 100 days from March 2027, 47 days from March 2029. This is the sample's answer to “how ready is the web?”

Two things stand out. The first is that the industry did comply, quickly and quietly: 0 certificates in the entire sample were issued after March 15, 2026 with a lifetime above the 200-day cap. The long tail of 79 certificates in the 201–398 day bucket is entirely made up of certificates issued before the cutoff, still running out their grandfathered validity.

The second is where the mass actually sits. Look at the exact lifetimes issuers choose:

The largest single cluster is 90 days — 32.4% of all certificates — the shape of ACME-style automated issuance. The second cluster is the giveaway: 58 certificates at 199 days and 32 at 198, sitting one or two days under the legal maximum. That is not a security decision; it is manual renewal buying itself as much runway as the rules allow.

Which is exactly why the 47-day cap will hurt. A site on a 199-day certificate renews under two times a year — a calendar reminder handles that. At 47 days it is roughly eight renewals a year, and every one of them is an outage if a human forgets. The 42.7% of domains already living on lifetimes of 90 days or less are not more secure than the rest today; they are simply the ones that have already paid for automation.

Renewal pressure is visible in the sample right now: 7 domains (2%) were within 14 days of expiry when we scanned, and another 13 were inside the 30-day window. 3 had already expired outright.

Protocol floor

TLS 1.3 has won at the top — and TLS 1.0 has not left

Two separate handshakes per domain: one as a modern client, and one deliberately capped at the deprecated versions to see whether the server still answers.

84.8% negotiate TLS 1.3; the remaining 15.2% top out at TLS 1.2. Nothing in the sample negotiated anything older with a modern client — the floor has genuinely moved.

Then we asked the same servers a rude question: will you still speak TLS 1.0 or 1.1 if that is all I have?

91 domains (26.1%) completed a TLS 1.0 handshake. RFC 8996 deprecated TLS 1.0 and 1.1 in March 2021; browsers stopped offering them in 2020. And yet this is not a tail of neglected hobbyist servers — it includes some of the largest properties on the internet, sitting behind the largest CDNs, where the minimum protocol version is a per-customer setting that ships permissive by default and is rarely changed.

We double-checked this one with an independent client (OpenSSL 3.6, security level lowered so the old protocols could be offered at all) before publishing it, because it is the kind of number that gets quoted: the handshakes really do complete.

Is it dangerous? Only situationally. Modern clients never downgrade themselves, so the risk is a client that can be pushed into an old protocol on purpose. But it is dead weight with a real cost — it keeps CBC-mode ciphers and the 2010s attack surface alive for the sake of a client population that rounds to zero. In our grading it caps the domain at C, which is where most of the sample's C grades come from.

Scores

Graded A+ to F

The same deterministic grader that runs on /health, applied without exception to every domain that answered.

59.9% land on an A or A+ — a well-run certificate, a complete chain, TLS 1.3, nothing expired. The 22.6% sitting at C are almost entirely the legacy-protocol group from the previous section: accepting TLS 1.0 caps the grade there no matter how modern everything else is. Only 3 domains failed outright, each for the same unglamorous reason — a certificate that had already expired.

The single most common defect on the list is one almost nobody would guess: 29.5% of these domains serve a certificate chain containing a SHA-1 signature.

Chain hygiene otherwise is excellent: 99.7% served a complete chain, with exactly 1 domain missing an intermediate. Ten years ago this was one of the most common misconfigurations on the web; at this level of the market it is effectively solved.

Post-quantum

Post-quantum certificates: 0

We looked for ML-DSA and SLH-DSA in both the public key and the signature algorithm of every certificate in the chain. We found none — and that is the expected answer, not a scandal.

Every certificate measured — 349 of 349 — is signed with classical cryptography: 65.3% sha256WithRSAEncryption, the rest ECDSA with SHA-256 or SHA-384. On the schedule in NIST IR 8547, all of it is deprecated after 2030 and disallowed after 2035.

Three reasons the number is zero, and none of them is complacency:

• No CA can issue one. Publicly trusted issuance follows the CA/Browser Forum baseline requirements, and the post-quantum signature algorithms are not yet permitted there. A certificate nobody may issue cannot appear in a scan.
• No browser would accept one. Trust stores and TLS libraries have to ship the code points, the verification code and the policy first. Until they do, a post-quantum certificate is an outage, not an upgrade.
• The sizes are brutal. An ML-DSA-44 public key is 1,312 bytes and its signature 2,420 bytes, against 65 and about 71 bytes for ECDSA P-256. A served chain carries several of each, so a fully post-quantum handshake adds the better part of ten kilobytes before a single byte of content moves — on every new connection.

Worth separating two problems that get blurred together. Key exchange is urgent, because traffic captured today can be decrypted later once a quantum computer exists — and that migration is already underway in browsers and CDNs through hybrid schemes. Signatures only have to resist an attacker at the moment they are verified, so a certificate issued in 2030 with a 47-day lifetime is a much smaller problem than a session key recorded in 2026. Our scan measures the signature side only; it does not record which key-agreement group was negotiated, so this report has no number for hybrid key exchange, and we would rather say so than guess.

The missing third

151 of 500 domains never answered

Only 69.8% of the list produced a measurement. That number says more about how the ranking is built than about the health of the web, and it deserves an explanation rather than a footnote.

80.8% of the failures are domains with no address record at the apex at all. A ranking built from DNS resolution traffic is full of names that were never websites: CDN and telemetry zones, app-update endpoints, ad-delivery infrastructure. They rank enormously high because software resolves them constantly — and there is nothing listening on port 443 at the bare name.

23 more timed out, overwhelmingly hosts that are slow or unreachable from a single European vantage point, which is a fair description of a good part of the Chinese-hosted top of any global list. 3 resolved into reserved address space, which our scanner refuses to connect to by design.

We could have inflated the success rate by filtering the list first — dropping names without web content, retrying failures, following redirects to a www host. We did not, because the moment a study starts curating its own sample it stops being reproducible. What you see is the top 500 of a published list, scanned once, with every outcome reported.

Methodology

How this was measured

Everything needed to reproduce, criticize or dispute the numbers above.

The sample

Domains come from the Tranco research ranking (list JZ8PY, published 2026-08-19), a 30-day aggregation of five underlying rankings that is designed to be stable and hard to manipulate. We took the first 500 ranks, unfiltered, and scanned each name exactly once. The SHA-256 of the exact CSV we read is recorded in the summary file, so the input is pinned.

This sample is not the web. It is the top of one ranking: large, professionally operated properties, heavily concentrated behind a handful of CDNs and CAs. Expect every number here to be better than the internet at large, and expect a single CDN's default configuration to show up dozens of times as if it were dozens of independent decisions.

The measurement

• One TCP connection to port 443, SNI set to the domain, from a single machine on a single IP address in Europe. No HTTP request is ever sent — this is a TLS handshake and nothing else, so no page is fetched, no robots directive applies and there is no User-Agent involved.
• A second, deliberately antique handshake per domain, capped at TLS 1.1 (and where that succeeds, a third capped at TLS 1.0), to test the protocol floor.
• 8 domains in flight at a time, 400 ms between waves, 8-second handshake timeout, 25-second outer watchdog, and no retries: a domain that fails is recorded as failed. The whole run took 234 seconds.
• The client is Node.js with OpenSSL defaults, offering both RSA and ECDSA signature algorithms. On servers that hold both certificate types, what we record is therefore the server's own preference for a modern client, not the only certificate it owns.
• IPv4 is preferred when a name resolves to both. Names that resolve into private, loopback or otherwise reserved address space are refused by the scanner and counted as failures.

What we deliberately do not check

• Trust. We describe the chain as served; we do not build a validated path to a root store, so “chain complete” here means every issuer → subject link matches, not “your browser trusts this site”.
• Revocation and transparency. No OCSP, no CRLs, no Certificate Transparency log lookups. A revoked certificate looks healthy to this scan.
• Cipher suites and key exchange. We record the negotiated protocol version and cipher name, but do not enumerate supported suites or record the key-agreement group — so this report says nothing about hybrid post-quantum key exchange.
• Anything beyond the apex name. No www fallback, no redirect following, no subdomains, no ports other than 443, one IP address per name.
• HTTP-level configuration. No HSTS, no headers, no content — none of it is visible without making a request, and we do not make one.

The grading

Grades come from the same deterministic function that powers the public health check: a fixed set of deductions applied to the scan report, with the report's own timestamp used as “now”, so the same scan always produces the same letter. Nothing was hand-adjusted for this report, and no domain was excluded after the fact.

Two grading choices worth knowing when you read the distribution: accepting TLS 1.0 caps a domain at C regardless of everything else, and a SHA-1 signature anywhere above the leaf costs points even when it is an inert self-signed root — which, as the section above explains, is what all of them were here.

The code

The batch runner is two small scripts in this site's repository — scripts/research/scan-batch.mts for the scan and scripts/research/aggregate.mts for the aggregation — sitting on top of the unmodified scanner and grader in lib/health/. They are not published on GitHub yet; when the Lab's core goes up, they go with it. Until then the identical measurement is available one domain at a time on /health, which is the honest way to verify any single row of our data.

Raw data

Take the numbers

Both files are released into the public domain under CC0 1.0. No attribution required — though a link back is how reports like this stay worth writing.

If you cite this report, cite the date with it — the web moves, and the whole point of the exercise is to run it again next quarter and show what changed.