Chain check
When ML-DSA certificates arrive, every certificate chain on the web gets heavier, and a chain that outgrows the server's first flight costs an extra round trip on every full handshake. This tool looks up a domain in a measured corpus of 8,151 real chains (Tranco top 10k, captured 2026-08-07), shows the chain the site serves today, and projects what that same chain weighs once post-quantum signatures replace the classical ones. A domain outside the corpus is measured live at the moment you ask, with the same capture and projection code the corpus went through.
Free checkers already exist that answer whether a site negotiates post-quantum key exchange today, and some also report the chain's current algorithms. This one asks the next question: what happens to your chain when the signatures migrate. The chain facts are measured; every projected byte is a projection under stated assumptions, and the page says which is which.
Checker
The whole corpus at a glance
Across all 8,151 measured chains, here is how each migration scenario lands against the two common windows. The p50 and p95 columns are projected first-flight bytes.
| Scenario | p50 | p95 | over IW10 | over IW20 |
|---|---|---|---|---|
| ML-DSA-44, full chain, SCTs stay classical | 16,810 | 21,499 | 85.1% | 0.1% |
| ML-DSA-44, leaf key only | 8,506 | 11,176 | 0.3% | 0% |
| ML-DSA-44, full chain, SCTs migrate too | 21,651 | 28,535 | 99.7% | 1.6% |
| ML-DSA-44, leaf key only, SCTs migrate | 14,565 | 18,272 | 48.7% | 0% |
| ML-DSA-44, full chain, SCTs to SLH-DSA-128s | 36,427 | 44,844 | 99.8% | 98.8% |
| ML-DSA-44, leaf key only, SCTs to SLH-DSA-128s | 30,621 | 34,571 | 99.7% | 51.6% |
| ML-DSA-65, full chain, SCTs stay classical | 22,282 | 28,495 | 99.5% | 1.5% |
| ML-DSA-65, leaf key only | 10,035 | 12,705 | 0.9% | 0% |
| ML-DSA-65, full chain, SCTs migrate too | 28,805 | 38,201 | 99.8% | 48.1% |
| ML-DSA-65, leaf key only, SCTs migrate | 18,717 | 22,456 | 99.7% | 0.1% |
| ML-DSA-65, full chain, SCTs to SLH-DSA-128s | 40,658 | 51,848 | 99.8% | 99.7% |
| ML-DSA-65, leaf key only, SCTs to SLH-DSA-128s | 32,150 | 36,100 | 99.7% | 51.7% |
The row worth sitting with is the first one. Published typical-chain models disagree about whether ML-DSA-44 fits the initial window, because each builds a different chain. Measured chains answer:85.1% of sites project past it, mostly because real chains run deeper than the models assume. The optimistic arithmetic places one intermediate in the chain, while two thirds of this corpus serves two. Leaf-only migration, by contrast, fits almost everywhere, which makes it the transition shape worth planning for.
The SLH-DSA rows answer a different question: what if CT logs, whose long-lived keys are the natural home for conservative hash-based signatures, sign SCTs with SLH-DSA-128s at 7,856 bytes each. Then the SCTs alone outweigh the certificates, and even leaf-only migration projects past IW10 for99.7% of sites and past IW20 for51.6%. Leaf-only stops being an escape hatch the moment the logs go hash-based.
How the projection works
Each site's chain was captured once, exactly as served, and parsed offline. The projection swaps only the measured signature and public-key bytes in each certificate for their FIPS 204 equivalents (and, in the SLH-DSA SCT scenario, each embedded log signature for its FIPS 205 size), all sized with OpenSSL 3.5.5 rather than copied from the standards so the DER wrapping is included. Names, SANs, extensions, SCT structure, chain depth, and whether the site transmits its root all stay exactly as measured. The flight adds the CertificateVerify signature and a measured 1,256-byte constant for the rest of the server's messages.
- Projection swaps only measured signature and SPKI bytes for FIPS 204 sizes; DNs, SANs, extensions and SCT structure keep their measured size.
- Chain depth and root transmission stay exactly as observed at capture time.
- Each embedded SCT today carries a ~71-byte ECDSA signature.
- The SLH-DSA-128s SCT scenario swaps each of those for a 7,856-byte hash-based signature (measured, OpenSSL 3.5.5); chain and handshake signatures stay on the selected ML-DSA parameter.
- Flight = projected chain + Certificate framing (12 + 5/cert) + CertificateVerify (signature + 4) + 1,256 bytes measured non-CV overhead (pqc-cert-matrix, one lab stack).
- Real servers may run initcwnd above IW10; the window is selectable for that reason.
What this does not tell you. Nothing here is a latency measurement, and this page does not know your server's configured congestion window, which is why the window is an input. The corpus is a snapshot: chains rotate, and a domain's row describes what it served on 2026-08-07. A live result describes the chain served to this tool's vantage point at the moment you asked, which can differ from what a CDN serves to you. Every projected figure is a projection, not a measurement of a post-quantum handshake; the corpus contains zero post-quantum certificates, and every published scan to date reports the same for the production web.
The two published halves this joins: per-site chain measurement against a transport budget exists for classical chains (Nawrocki et al., CoNEXT 2022), and post-quantum size arithmetic against the congestion window exists for typical chains (Kampanakis and Childs-Klein, MADWeb 2024). The flight constant and the budget framing come from pqc-cert-matrix (DOI 10.5281/zenodo.21749600), which measured per-message byte attribution across chain shapes.
Corpus: Tranco list ZJGPG, top 10,000, captured 2026-08-07; 8,151 chains in the corpus. The capture scripts and the full dataset are public at pqc-chain-budget(DOI 10.5281/zenodo.21846142); this page's data files are generated from that dataset and carry its stamps.