One private key, 1,029,213 domains: the shared TLS certificates with the largest blast radius
The September 2026 census completed a TLS (Transport Layer Security) handshake with 212,328,093 apex domains and kept the certificate each one presented. 187,104,045 distinct certificates came back. 184,180,105 domains (86.7%) presented a certificate that no other apex in the census presented. The remaining 28,147,988 (13.3%) presented one that at least one other apex also presented, and for 64.7% of those the browser rejects it for that domain.
At the top of the distribution sits one certificate. Shopify’s storefront placeholder, issued by Cloudflare for *.myshopify.com and served from Cloudflare’s edge, is presented by 1,029,213 apex domains across 576 top-level domains, and it is authorised for none of them. The 25 most-served certificates together cover 5,148,628 domains, 2.4% of the base, and browsers accept them for 9 of those domains in total. All 25 are placeholders: a hosting company’s wildcard for its own domain, a site builder’s default, or a self-signed certificate that shipped with the web server. Certificates that carry their presenting domains’ own names, the kind a content delivery network issues, don’t appear near the top at all: none of the 1,000 most-served certificates, each presented by at least 1,279 apexes, is accepted by the browser for more than 5.2% of the domains presenting it.
What a shared certificate is, and why its reach matters
A TLS certificate binds a public key to a list of names. The private half of that key sits on whatever server or edge answers for those names, and the certificate lists the names it can answer for in its subject alternative name field, the SAN list. When a scanner connects to two different apex domains and both hand back a certificate with the same SHA-256 fingerprint, they’re presenting the same certificate, and so the same private key.
That is normal. A hosting company’s server hands its default certificate, sometimes self-signed and sometimes a wildcard for the company’s own domain, to each domain parked on it that was left unconfigured. A site builder serves its own certificate to each storefront that hasn’t finished pointing its domain. An edge network terminates TLS for its customers and holds their keys. In each case the domain owner didn’t generate the key, can’t see it, and can’t rotate it.
The reach of one key is the point. Whoever holds it can present that certificate for every name on the list, and if it leaks, each of those names can be impersonated until the certificate is revoked or expires. With TLS 1.3, forward secrecy means a leaked key doesn’t expose recorded traffic, so impersonation is the whole risk. If the operator lets the certificate lapse, misissues it or has it revoked, all the names on it go down together. Certificate transparency logs and issuance studies count what was issued. They can’t say what a browser connecting to a given apex was handed on the day, and that is what the census measures.
Three kinds of sharing
The census separates three patterns, because they mean different things for the site owner.
The first is the hosting default: the provider’s own wildcard certificate, or a certificate for the server’s own hostname, served to each domain that resolves to that machine without a configured site of its own. The browser rejects it, because the domain’s name isn’t on it.
The second is the site-builder or commerce default: a platform’s own certificate, for the platform’s own domain, served to a customer apex that points at the platform but has no certificate of its own there yet. The browser rejects this too.
The third is the generic self-signed placeholder: the certificate the web server generated at install time, with an issuer like Internet Widgits Pty Ltd or a common name of localhost, and often no names at all. No one chose it: it’s what answers when a port was left open.
A fourth pattern, one certificate carrying several customers’ own names at a CDN edge, is one the browser accepts. At the apex the census rarely met it, as the section on Cloudflare-fronted domains below shows.
How many apexes present the same certificate
Each domain in the base sits in one row of this table, by how many apexes in the census presented the same certificate it did. “Browser rejects it” means the scanner’s TLS library, applying the same test a browser does, refused the certificate for that domain.
| Apexes presenting the same certificate | Certificates | Domains | Share of the base | Browser rejects it |
|---|---|---|---|---|
| 1 (its own) | 184,180,105 | 184,180,105 | 86.7% | 2.6% |
| 2 to 10 | 2,682,874 | 7,883,545 | 3.7% | 24.0% |
| 11 to 100 | 231,345 | 6,026,300 | 2.8% | 35.6% |
| 101 to 1,000 | 8,524 | 2,075,081 | 1.0% | 97.5% |
| 1,001 to 10,000 | 1,008 | 2,956,973 | 1.4% | 99.9% |
| 10,001 or more | 189 | 9,206,089 | 4.3% | 100.0% |
The table has two halves. In the 2 to 10 and 11 to 100 bands the browser accepts the certificate for most domains: these are working multi-name certificates with each presenting domain’s own name on them. From 101 apexes upward the shared certificate is almost always a placeholder. 189 certificates are each presented by more than 10,000 apexes. Between them they cover 9,206,089 domains, 4.3% of the base, and browsers accept them for 65 of those domains.
Figure 1. Domains on a shared certificate, by how many apexes present that certificate, split into domains the browser accepts it for and domains it rejects it for. The 184,180,105 domains on a certificate of their own are left out.
The split by top-level domain type is small. 12.8% of gTLD domains and 14.2% of ccTLD domains present a shared certificate. Among those, the browser accepts the certificate for 31.2% of the gTLD domains and 43.0% of the ccTLD domains, so the ccTLDs carry a little less placeholder and a little more working multi-name certificate.
What Cloudflare-fronted domains present
43,717,869 domains in the base, 20.6%, answered with a cf-ray header, which marks a response that came through Cloudflare. 97.5% of them presented a certificate that no other apex presented. Only 1,081,884 sat on a shared certificate, and 1,029,208 of those are the Shopify placeholder. For 42,571,976 of them (97.4%), all the names on the certificate sat under the domain’s own apex and the browser accepted it, and 72.5% carried a wildcard name. For these domains the TLS connection ends at Cloudflare’s edge, which is where the key is used, and the certificate itself names no other customer.
How many names one certificate carries
The same base, grouped by the number of DNS (Domain Name System) names in the presented certificate’s SAN list. A certificate with no SAN entry at all is a placeholder by definition: no modern browser accepts a certificate for a name that isn’t in the SAN list.
| Names on the certificate | Domains | Share of the base | gTLD | ccTLD | Browser rejects it | Names outside the domain’s own apex |
|---|---|---|---|---|---|---|
| None | 3,506,780 | 1.7% | 1.8% | 1.4% | 100.0% | 0.0% |
| 1 | 71,869,689 | 33.8% | 37.7% | 25.7% | 6.4% | 4.7% |
| 2 to 10 | 128,435,280 | 60.5% | 56.5% | 68.9% | 10.6% | 12.6% |
| 11 to 100 | 8,371,033 | 3.9% | 4.0% | 3.9% | 16.6% | 98.0% |
| More than 100 | 145,311 | 0.1% | 0.1% | 0.1% | 34.6% | 100.0% |
Most of the HTTPS (Hypertext Transfer Protocol Secure) internet runs on small certificates: 60.5% of domains present one with two to ten names, and another 33.8% present one with a single name. In the two to ten band, 87.4% of domains present a certificate on which all the names are the domain itself or names under it. The large SAN pack is rare at the apex. 145,311 domains, 0.1% of the base, present a certificate with more than 100 names, and the browser rejects that certificate for 34.6% of them.
Figure 2. Domains by the number of DNS names on the certificate they present, split into domains the browser accepts it for and domains it rejects it for.
Wildcards are common. 71,675,949 domains (33.8%) present a certificate with at least one wildcard name, 34.1% of gTLD domains and 33.0% of ccTLD domains. Only 603,203 (0.3%) present one on which all the names are wildcards.
Wildcards by issuer
The ten certificate authorities serving the most domains account for 96.5% of the base. Each row’s shares are of that issuer’s own domains. “Browser rejects it” for an issuer means its certificate was presented by a domain it isn’t valid for, which is a statement about where the certificate ended up, and says nothing about the issuer.
| Issuer | Domains | Share of the base | Wildcard name on the certificate | Browser rejects it | Names outside the domain’s own apex |
|---|---|---|---|---|---|
| Let’s Encrypt | 118,359,957 | 55.7% | 27.0% | 6.9% | 12.6% |
| Google Trust Services | 39,692,528 | 18.7% | 68.2% | 0.2% | 5.0% |
| GoDaddy, including Starfield | 25,419,779 | 12.0% | 0.7% | 1.3% | 1.2% |
| Sectigo, including Comodo | 8,984,209 | 4.2% | 59.8% | 43.9% | 41.0% |
| DigiCert, including GeoTrust, Thawte and RapidSSL | 4,951,996 | 2.3% | 34.4% | 41.0% | 39.9% |
| ZeroSSL | 2,316,409 | 1.1% | 14.2% | 7.2% | 9.8% |
| Amazon | 1,575,080 | 0.7% | 57.7% | 11.4% | 30.0% |
| GlobalSign | 1,294,838 | 0.6% | 60.9% | 62.3% | 60.6% |
| Actalis | 1,113,557 | 0.5% | 97.5% | 5.9% | 5.6% |
| Cloudflare | 1,092,369 | 0.5% | 99.3% | 100.0% | 99.1% |
GoDaddy’s certificates almost never carry a wildcard (0.7%), and the browser accepts them for 98.7% of the domains presenting them. Google Trust Services certificates carry one for 68.2% of the domains presenting them and are accepted for 99.8%. Sectigo and DigiCert sit in the middle on wildcards and much lower on acceptance, rejected for 43.9% and 41.0% of their domains. 14 of the 25 certificates in the table further down, presented by 2,547,550 domains between them, were issued by one of the two. Cloudflare’s own issuing authority is at 99.3% wildcard and 100.0% rejected, and the Shopify placeholder alone accounts for 94.2% of its domains.
Figure 3. Wildcard share for the ten issuers serving the most domains, with each issuer’s domains and the share of them the browser rejects the certificate for.
Beyond the ten, 3,597,479 domains (1.7%) present a certificate with no recognisable issuer at all: an empty issuer field, or a placeholder organisation like Internet Widgits Pty Ltd, Plesk, or a control panel’s name. The browser rejects the certificate for 99.7% of them.
The 25 certificates presented by the most apex domains
Each row is one certificate, identified by its SHA-256 fingerprint, labelled by the platform its own issuer, common name and server header identify. No customer name appears in the table, and the platform label says who served the certificate; it says nothing about who owns the domains presenting it. The issuer column gives the certificate authority’s family name, or, for a self-signed certificate, the organisation the certificate itself names. Where the common name is a hosting company’s infrastructure domain, such as kasserver.com, web-hosting.com, dadapro.com, your-server.de, domainparking.ru, hostingplatform.com, turbifysites.com or stackcp.com, the label also names the company that operates that domain, which is public knowledge of who runs it and the one step this page takes beyond the certificate’s own fields.
| # | Certificate | Issuer | Names | Apex domains | TLDs | Browser rejects it |
|---|---|---|---|---|---|---|
| 1 | Shopify storefront default (*.myshopify.com, served from Cloudflare’s edge) | Cloudflare | 2 | 1,029,213 | 576 | 100.0% |
| 2 | All-Inkl.com hosting default (*.kasserver.com) | Sectigo | 2 | 430,121 | 441 | 100.0% |
| 3 | Namecheap shared-hosting default (*.web-hosting.com) | Sectigo | 2 | 363,716 | 612 | 100.0% |
| 4 | Squarespace default (*.squarespace.com) | DigiCert | 14 | 342,151 | 580 | 100.0% |
| 5 | OpenSSL self-signed placeholder (issuer ‘Internet Widgits Pty Ltd’, no names) | Internet Widgits Pty Ltd | 0 | 327,734 | 322 | 100.0% |
| 6 | Dada group hosting default (*.dadapro.com; Register.it, Nominalia, Amen) | Sectigo | 2 | 260,042 | 499 | 100.0% |
| 7 | one.com hosting default (*.one.com) | Let’s Encrypt | 2 | 237,940 | 406 | 100.0% |
| 8 | DreamHost default (sni.dreamhost.com, self-issued) | New Dream Network LLC dba Dreamhost | 0 | 237,860 | 573 | 100.0% |
| 9 | HostGator default (*.hostgator.com) | DigiCert | 2 | 171,178 | 526 | 100.0% |
| 10 | nginx self-signed placeholder (issuer ‘MyCompany Inc.’, CN ‘default’) | MyCompany Inc. | 0 | 157,603 | 5 | 100.0% |
| 11 | vdx.nl shared-hosting default (*.vdx.nl) | Sectigo | 2 | 156,514 | 376 | 100.0% |
| 12 | Sakura Internet default (*.sakura.ne.jp, 64 names) | Gehirn Inc. | 64 | 132,476 | 248 | 100.0% |
| 13 | Hetzner default (*.your-server.de) | DigiCert | 2 | 127,009 | 490 | 100.0% |
| 14 | REG.RU domain-parking default (*.domainparking.ru) | GlobalSign | 2 | 115,072 | 62 | 100.0% |
| 15 | Crazy Domains hosting default (*.crazydomains.com) | Sectigo | 2 | 113,720 | 348 | 100.0% |
| 16 | Web.com / Network Solutions hosting default (*.hostingplatform.com) | Sectigo | 2 | 111,404 | 367 | 100.0% |
| 17 | Bluehost default (*.bluehost.com) | Sectigo | 2 | 107,629 | 476 | 100.0% |
| 18 | Beget hosting default (beget.com) | Let’s Encrypt | 2 | 106,839 | 232 | 100.0% |
| 19 | Turbify sites default (*.turbifysites.com, formerly Yahoo Small Business) | DigiCert | 2 | 100,911 | 187 | 100.0% |
| 20 | Bizland hosting default (*.bizland.com) | Sectigo | 2 | 95,619 | 442 | 100.0% |
| 21 | ‘localhost’ self-signed placeholder (Apache and CentOS builds) | localhost | 0 | 88,097 | 201 | 100.0% |
| 22 | ‘localhost.localdomain’ self-signed placeholder (issuer ‘SomeOrganization’) | SomeOrganization | 0 | 84,702 | 38 | 100.0% |
| 23 | 20i StackCP hosting default (*.stackcp.com) | DigiCert | 2 | 83,782 | 427 | 100.0% |
| 24 | Hostpoint hosting default (*.hostpoint.ch) | Sectigo | 2 | 83,754 | 425 | 100.0% |
| 25 | WordPress.com default (wordpress.com and *.wordpress.com) | Let’s Encrypt | 2 | 83,542 | 484 | 100.0% |
By class, 17 of the 25 are a hosting provider’s own certificate, served to 2,934,675 domains (57.0% of the top-25 total). 4 are a site builder’s or commerce platform’s own certificate, on 1,555,817 domains (30.2%). 4 are generic self-signed placeholders with no provider on them at all, on 658,136 domains (12.8%). None of the 25 is a certificate that carries its presenting domains’ names.
Figure 4. The 25 most-served certificates, by the apex domains presenting each. The shape beside each bar marks its class: a circle for a hosting provider’s own certificate, a square for a site builder’s, a triangle for a self-signed placeholder.
Two rows show the range. The Shopify placeholder is served for 1,029,213 apexes in 576 TLDs, 910,942 of them gTLD and 118,271 ccTLD: each is a domain pointed at Shopify’s edge with no certificate of its own there, and the browser rejects the certificate for each of them. The nginx placeholder at row 10 is served for 157,603 apexes in 5 TLDs, 97.6% of them under .xyz.
The row-1 certificate is what 1,029,213 apexes hand a visitor, and the row-2 certificate is what 430,121 do. Both certificates name the platform as their subject, and none of the domains presenting them can rotate either key.
By top-level domain
The twelve TLDs with the most domains in the base. “Shared” is the share of that TLD’s domains presenting a certificate that at least one other apex, in any TLD, also presents; “1,001 or more” narrows that to certificates presented by more than a thousand apexes.
| TLD | Domains in the base | Shared certificate | Certificate shared by 1,001 or more apexes | Browser rejects the certificate |
|---|---|---|---|---|
| .com | 99,672,803 | 12.5% | 5.7% | 10.5% |
| .de | 8,964,025 | 15.8% | 6.3% | 17.1% |
| .org | 6,717,905 | 13.4% | 5.3% | 10.3% |
| .xyz | 6,377,394 | 7.0% | 5.2% | 6.9% |
| .net | 6,019,123 | 16.6% | 7.7% | 14.9% |
| .uk | 5,347,256 | 10.1% | 3.2% | 6.2% |
| .ru | 3,275,253 | 17.2% | 10.9% | 18.4% |
| .br | 3,185,846 | 8.0% | 2.6% | 8.1% |
| .nl | 3,176,014 | 23.5% | 6.7% | 14.4% |
| .cn | 3,173,494 | 25.3% | 6.0% | 14.0% |
| .fr | 2,518,345 | 13.0% | 3.9% | 7.5% |
| .top | 2,512,565 | 15.8% | 6.5% | 12.8% |
The spread is wide. In .cn, 25.3% of domains present a shared certificate, and in .nl 23.5%; in .xyz it’s 7.0% and in .br 8.0%. What sits on those shared certificates varies as much. Among the domains on a shared certificate, the browser accepts it for 54.1% in .cn, 52.4% in .br, 52.3% in .fr and 52.1% in .uk, against 15.2% in .xyz and 13.0% in .ru.
A key you don’t hold
28,147,988 domains, 13.3% of the base, present a certificate that at least one other apex presents, so the private key behind their HTTPS sits behind other apexes’ HTTPS too. For 18,216,873 of them (64.7%) the browser rejects that certificate: HTTPS is switched on, and what answers is a certificate for the platform’s own name, or for no name at all. For the other 9,931,115 (35.3%) it works: their name is on a certificate alongside other apexes, and the key sits with whoever terminates TLS for all of them.
A second count, made inside each certificate instead of across the census, lands close by. 27,895,332 domains (13.1%) present a certificate that names at least one thing outside their own apex. For 12,327,130 of those (44.2%) their own name is on it too, so the certificate is a working multi-name one. For the other 15,568,202, it isn’t.
Seen from the other side, 23,068,965 domains (10.9%) present a certificate the browser rejects, and 67.5% of those present one carrying somebody else’s names, so most of the internet’s broken HTTPS is someone else’s certificate. The remaining 7,500,763 is a certificate with no names at all, or one whose names all sit under the domain’s own apex and which fails for another reason, such as expiry, a self-signed chain, or a www-only name that doesn’t cover the apex. The TLS pillar walks through the browser warning each of those produces.
What the census can and can’t see
- The scan connected to the apex name of each domain once, with that name in the TLS server name indication field, and kept the leaf certificate the server chose to present. It didn’t visit www or any other subdomain, and it didn’t retry with a different name.
- Two domains presenting the same fingerprint are presenting the same certificate and therefore the same key. The reverse doesn’t hold: two different certificates can be issued for the same key, so the sharing counted here is a floor.
- A shared fingerprint says two apexes present one certificate. It doesn’t say who owns either domain. A company that puts fifty of its own brands on one certificate shows up in the same band as a platform serving fifty unrelated customers, and the census can’t tell them apart. Platform labels on this page come from the certificate’s issuer, its common name and the server header, plus the public identity of the company operating an infrastructure domain that the common name gives, and not from the customer names on the certificate.
- Names inside SAN lists were counted and tested against the presenting domain; none was stored or published. A name counts as outside the presenting domain’s apex if it is neither the apex itself nor a name beneath it.
- “Browser rejects it” means the scanner’s TLS library, applying the same test a browser does, refused the certificate for that domain: the chain didn’t verify, or the name didn’t match. A shared certificate the browser accepts for a domain carries that domain’s name; one it rejects is a default or a mismatch.
- The base is each scanned domain, whatever its census disposition, that completed a TLS handshake on the apex and presented a certificate the scan captured: 212,328,093 of 347,691,016 scanned domains, 61.1%. It is wider than the graded-plus-dead base the census grades use, and it is the base for all the shares on this page unless a table says otherwise. All domains that completed a handshake also presented a certificate; the two counts are equal.
- Where a domain was scanned twice, the later pass counts once. gTLD and ccTLD follow the IANA (Internet Assigned Numbers Authority) root zone database’s type column: country-code is ccTLD, everything else is gTLD.
- Issuers are grouped by the organisation on the certificate, with a company’s older brands folded in: Starfield under GoDaddy, Comodo under Sectigo, GeoTrust, Thawte and RapidSSL under DigiCert.
- Certificate lifetimes, key types and TLS versions are published elsewhere at comparable scale, so this page leaves them out.
See your own
The free scan connects to your apex the same way the census did and checks whether the certificate it was handed is valid and trusted for your domain. HSTS covers what to set once the certificate is right, and how the domains were counted explains the census states behind this page’s base.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the data page.