Defaults.Exposed › Reports

Self-Signed Certificates: The 3.3 Million-Domain Census

Published 2026-08-18

Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: 3.3 million self-signed certificates, and a million of them are literally the tutorial default

Across 231,455,163 domains that presented a TLS certificate in our August 2026 census, approximately 18.6 million certificates failed validation against the public trust store, and 3,306,642 of them were self-signed. That second number has a texture the first one doesn’t. When we sorted the untrusted certificates by the organisation name baked into the issuer field, the list read less like an internet and more like an abandoned classroom: Internet Widgits Pty Ltd. My Company Ltd. SomeOrganization. localhost. testexample.

Those are not companies. They are the placeholder strings that ship inside OpenSSL prompts, hosting-panel installers and ten thousand copy-paste tutorials. Nobody chose them. Nobody was supposed to keep them. Across just 20 unmistakable placeholder issuer strings, we counted 1,008,580 certificates — roughly a million domains serving the internet’s equivalent of a form letter still addressed to [YOUR NAME HERE].

Every one of those certificates makes a browser throw a full-screen warning. And every day, people click through, because the site behind the warning is one they actually need. That is the real story here. The self-signed web is the largest click-through-the-warning training programme ever run, and nobody is running it on purpose.

Key numbers

• 231,455,163 graded domains presented a TLS certificate in the August 2026 census — 61.4% of the 376,928,781 domains graded.
• Approximately 18.6 million certificates (8.0% — about 1 in 13) failed validation against the public trust store at capture time.
• 3,306,642 certificates were self-signed: 1.43% of every certificate presented, and 17.8% of everything that failed validation.
• 375,842 certificates carry the issuer “Internet Widgits Pty Ltd” — the literal OpenSSL example default. That’s 11.4% of the entire self-signed pool.
• 1,008,580 certificates across 20 placeholder issuer strings (My Company Ltd, SomeOrganization, localhost, testexample and friends) — pure software-default artifacts.
• At least 305,779 untrusted certificates trace to hosting-control-panel default issuers (the Plesk family, cPanel, DirectAdmin, FASTPANEL, Hestia, aaPanel/BT Panel, Kangle) in our top-200 issuer list alone.

What is a self-signed certificate, and why does the browser warn you?

A TLS certificate does two jobs. It carries the key material that encrypts the connection, and it carries a signature from a certificate authority vouching that the key really belongs to that domain. A self-signed certificate does the first job and skips the second. The server vouches for itself. Cryptographically it says “trust me”, signed, “me”.

Encryption still works over a self-signed certificate. What’s missing is any reason to believe you’re encrypting to the right party, which is why every mainstream browser interrupts the page with a warning you have to actively dismiss. The warning is doing its job. The problem is what three million of them, spread across the everyday web, do to the humans who see them.

Here is the thing that makes 2026 a strange year for this number to still exist: a publicly trusted certificate has been free since Let’s Encrypt launched in 2015, and it is now the default happy path on most modern hosting. Our own data shows how completely that battle was won — 104,403,703 valid certificates in this census chain up to Let’s Encrypt, nearly half of everything presented. The 3.3 million self-signed certificates are not a cost problem. They are an awareness problem, and mostly not even a human one, as the issuer names are about to demonstrate.

Who “issued” the self-signed web? Nobody.

Group the untrusted certificates by the organisation string in their issuer field and the software defaults identify themselves. These are the placeholder issuers from our top-200 issuer table — names no registrar ever incorporated:

The provenance labels in the right-hand column are industry knowledge — well-documented software defaults — not something the census can observe directly. But the counts are ours, and the pattern needs no interpretation. Nearly a third of the classified self-signed pool (1,008,580 of 3,306,642, 30.5%) wears a name that was never meant to survive first contact with a keyboard.

“Internet Widgits Pty Ltd” deserves its own sentence. It is the default organisation name in OpenSSL’s certificate-request prompt, a joke entry that has shipped with the world’s most widely deployed cryptography library for decades. When someone runs the standard one-liner to generate a certificate and presses Enter through the prompts, Widgits is what comes out. It now fronts 375,842 domains — one in nine of every self-signed certificate on the measurable web. It may be the most successful fictional company in history.

Which software ships these certificates by default?

The second population is more interesting than the tutorial-follower cohort, because no human generated these certificates at all. Hosting control panels and appliances mint a self-signed certificate automatically at install time, so that the admin interface and any not-yet-configured site can serve HTTPS immediately. It’s a sensible bootstrap. The certificate is supposed to be replaced the moment a real one is provisioned.

Counting only issuer strings we could confidently attribute in our top-200 list, at least 305,779 untrusted certificates came out of hosting-panel installers: the Plesk lineage (Plesk, Parallels, Odin) at 184,903, cPanel at 48,089, the aaPanel/BT Panel family at 29,368, FASTPANEL at 14,936, Hestia at 12,753, Kangle at 9,322 and DirectAdmin at 6,408. Appliance vendors show up the same way — Fortinet (4,165), Synology (4,758) and WatchGuard (1,804) device certificates, all facing the public internet on a domain that got scanned.

One notable artifact hides in plain sight: the single largest untrusted bucket that isn’t a real CA is 1,726,122 certificates with an empty issuer-organisation field. Our grouping is by organisation string, so we can’t decompose that bucket precisely, but it is where organisation-less default certificates land — including Traefik’s well-known “TRAEFIK DEFAULT CERT”, which sets only a common name and no organisation (that attribution is industry knowledge about how Traefik builds its fallback certificate, not a census measurement). A reverse proxy that ships a built-in fallback certificate, multiplied across every half-configured deployment, adds up.

None of this is an indictment of the vendors. Bootstrap certificates are the right engineering call. The finding is about what happens after the bootstrap: hundreds of thousands of installs where step two — replace the placeholder — simply never occurred, and the placeholder has been greeting visitors with a browser warning ever since.

Does an untrusted certificate always mean self-signed?

No, and this distinction matters for reading every table above. “Failed validation” (our authorized=false state) is a bigger tent than “self-signed”. A certificate can fail because it’s self-signed, because it expired, because the server never sent the intermediate certificate that completes the chain, or because it was issued for a different hostname. Of the approximately 18.6 million failing certificates, 3,306,642 — about one in six — carry self-signed fingerprints. The rest failed for chain, expiry and mismatch reasons.

The proof is at the top of the failure table. The issuer with the most non-validating certificates in this census is Let’s Encrypt, at 7,171,332 — obviously not self-signed, since Let’s Encrypt signed them. Those are real certificates that had expired or arrived with broken chains at the moment we looked. Sectigo (2,773,915) and DigiCert (1,449,205) follow the same pattern.

One more measurement nuance: 1,006,164 failing certificates name “CLOUDFLARE, INC.” as issuer. These are consistent with Cloudflare Origin CA certificates — certificates designed to secure only the private hop between Cloudflare’s edge and the origin server, never intended to be publicly trusted (again, industry knowledge about that product, not a census observation). A visitor routed through Cloudflare never sees them; our scanner, reaching an origin directly, does. They are the one large bucket in this report where “untrusted” is arguably working as designed.

Why does a million browser warnings matter?

Because warnings only work if they’re rare.

Browser security UI runs on a simple economy: the full-page interstitial is scary precisely because users almost never see it, so seeing one means something is genuinely wrong. Every self-signed certificate on a site people actually need — the office NAS, the church website, the club booking page, the panel login the IT contractor bookmarked — spends down that scarcity. The user learns the sequence: warning, Advanced, Proceed anyway. The third time it takes four seconds. By the tenth time it’s muscle memory.

That muscle memory is exactly what a real attack needs. A machine-in-the-middle attack against a properly certificated site produces the same interstitial that 3.3 million legitimate-but-lazy configurations have been teaching people to dismiss. The self-signed web isn’t dangerous mainly because those specific sites are impersonatable. It’s dangerous because it trains everyone, at scale, for free, to click through the one warning that was supposed to be non-negotiable.

The fix costs nothing, which is the recurring finding of this census in miniature. A trusted certificate is free, automated and often one checkbox away in the very panels that minted the placeholder. The barrier is not money and it is not difficulty. It is that nobody told the owner the warning page was theirs.

How we measured this

• Population and denominator: 376,928,781 graded domains from the August 2026 census round (graded-only basis; figures as of 16 August 2026, methodology v9). Of these, 231,455,163 presented a TLS certificate during scanning, and that figure is the denominator for every percentage in this article unless stated otherwise.
• Validation: a certificate counts as failing validation when our TLS client could not chain it to the public trust store at capture time (the authorized=false state). The issuer analysis in this article is built on exactly this basis.
• Self-signed classification: 3,306,642 certificates carry self-signed fingerprints per our certificate-problem classification. Failed validation is not the same as self-signed — expired certificates, incomplete chains and hostname mismatches also fail, and the Let’s Encrypt row above is the proof. We keep the two numbers separate throughout.
• Issuer analysis: grouped by the certificate’s issuer organisation string (top 200 combinations by volume). String grouping splits vendors that vary their spelling and cannot decompose the empty-organisation bucket. Placeholder-string and panel-default totals therefore count only the strings we could confidently identify in the top 200; both are floors, not ceilings.
• Attribution labels (which software ships which default string, Origin CA behaviour, EOL-style product lineage) are public industry knowledge, stated as such inline. The census measures the strings and the counts; it does not observe provenance.
• Snapshot, single vantage: validity was measured at capture time from our EU measurement infrastructure. A certificate that expired the day after we scanned counts as valid; one renewed the day after counts as failed. Direct-origin scanning also sees certificates (like origin-pull certificates) that CDN-fronted visitors never encounter.
• Aggregate only. We report counts and issuer strings. We never name, grade or publish data about an individual registrant’s domain.
• Data is stored and processed within the EU.

FAQ

Is a self-signed certificate ever acceptable? Yes — on genuinely private infrastructure: lab environments, internal services with the certificate explicitly pinned or the private CA installed on every client, and appliance bootstrap screens that never face the internet. The 3,306,642 in this census fail that test by definition: they were presented on public, resolvable domains our scanner could reach, where a free trusted certificate would remove the warning entirely.

Is my data encrypted if I click through the warning? The connection is usually encrypted, yes. What you’ve lost is authentication: any proof that the encrypted tunnel ends at the party you think it does. Encryption to an unverified endpoint protects you from passive snooping but not from an active impersonator — which is precisely the scenario the dismissed warning exists to catch.

What is “Internet Widgits Pty Ltd”? It is the default organisation name in OpenSSL’s certificate-generation prompts — placeholder text that has shipped with the library for decades. Anyone who presses Enter through the prompts gets it. As of our 16 August 2026 census round it fronts 375,842 certificates, 11.4% of all self-signed certificates we classified.

How common are self-signed certificates in 2026? Rarer than folklore suggests, and stubbornly persistent. Of 231.5 million domains presenting a certificate, 1.43% are self-signed and approximately 8.0% fail trust-store validation for any reason. The web’s encryption upgrade genuinely happened — more than nine in ten presented certificates chain to the public trust store — but the failing tail is measured in millions of domains, and a million of those are pure software-default artifacts.

How do I replace a self-signed certificate for free? Use an ACME client (Certbot is the best known) or the built-in Let’s Encrypt integration that ships in cPanel, Plesk and most modern panels — frequently the same panels whose installer minted the placeholder certificate in the first place. Issuance is automated, renewal is automatic, and the cost is zero. If your site shows a certificate warning today, this is almost always a minutes-long fix.

What should I do if my domain is showing a self-signed certificate? Log into your hosting panel — cPanel, Plesk, DirectAdmin and most others have a built-in Let’s Encrypt button. Click it, wait 60 seconds, and the warning disappears permanently. If you are running your own server, install Certbot and run certbot --apache or certbot --nginx. Renewal is automatic from that point. There is no cost and no ongoing maintenance. If you manage multiple domains, run a scan across all of them first — the warning often appears on subdomains and staging environments the owner has forgotten about.

How does this compare to the previous census (July 2026)? The August 2026 census is the first full measurement of this population at this scale under methodology v9. The July 2026 round established the baseline; August re-measures the same population with an expanded 432-million domain sweep. Direct percentage comparison requires the July issuer extract, which is in preparation. What we can say is that the free-certificate infrastructure that should be eliminating this problem — Let’s Encrypt at 104 million valid certificates — is clearly working for the majority. The 3.3 million self-signed certificates represent the residual where automation or awareness has not yet reached.

Why does this matter for small business owners? A browser security warning on your business website is invisible to you and catastrophic for visitors. Browsers do not send you an email when they block your customers; those customers simply leave, or worse, they click through and learn that this is what “the warning on a dodgy site” feels like. The businesses most likely to be running unnoticed self-signed certificates are the ones that set up hosting years ago and have not revisited it — exactly the profile of a small business owner who is not a developer. The certificate itself is free and takes minutes to fix; the cost of not fixing it is every visitor who bounced off the warning page.

What this means

If your organisation’s public-facing domain is throwing a browser security warning, your visitors are seeing a full-screen red page telling them something is wrong before they see a single word of your content. Search engines are also watching: a failing certificate is a signal that the site may be unmaintained. IT managers should treat any certificate validation failure as a P1 issue — not because encryption is broken, but because the authentication layer is gone and because every click-through trains your users to ignore the one warning that matters.

Security teams need to audit beyond the main domain. The census data shows that self-signed and placeholder certificates accumulate on subdomains, staging environments, internal-facing admin panels, and network appliances — exactly the infrastructure that gets set up once and forgotten. A Plesk, cPanel or DirectAdmin bootstrap certificate on a forgotten subdomain is a live browser warning your business is serving to anyone who finds that URL. Periodic scans of the full subdomain inventory, not just the homepage, are the only way to find them.

For business owners without in-house technical staff: the fix is genuinely free and usually takes under five minutes. Every major hosting provider has a one-click Let’s Encrypt button. The practical risk of ignoring this is not just reputational — a self-signed certificate also means you have no cryptographic proof that your customers are talking to you rather than an impostor. In a world where phishing is the primary attack vector against small businesses, that verification gap is the one thing you cannot afford to leave open.

Data to cite

“3,306,642 certificates out of 231.5 million observed on the public web were self-signed — 1.43% of all certificates presented — in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Approximately 18.6 million TLS certificates — 8.0%, roughly 1 in 13 — failed validation against the public trust store in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“375,842 domains serve a certificate issued by ‘Internet Widgits Pty Ltd’ — the unedited OpenSSL example default, unchanged since the 1990s.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Across just 20 placeholder issuer strings, 1,008,580 certificates exist on the public internet purely as software-default artifacts — no human chose any of these names.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“At least 305,779 untrusted certificates on live public domains trace to hosting-panel default issuers, including Plesk, cPanel, and DirectAdmin — bootstrap certificates that were never replaced.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“More than nine in ten certificates presented on the measured web do chain to the public trust store — the free-certificate infrastructure works; the 3.3 million self-signed certificates are an awareness and automation failure, not a cost problem.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

A browser warning on your own domain is the kind of thing nobody tells you about — visitors just leave. Our census grades real, live domains across externally observable security checks, certificate validity included, and most of what a failing domain is missing is free and quick to fix. The barrier is almost never cost; it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.

Check your domain free at defaults.exposed — see exactly how your domain scores on certificate trust and validation. Takes 30 seconds. No account needed. Read the flagship census report: The State of Domain Security 2026 →

Related from this census: TLS 1.3 adoption report · Weak and outdated TLS · The HTTP security header report card

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). Self-Signed Certificates: The 3.3 Million-Domain Census. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/self-signed-certificates-census-2026

Academic: defaults.exposed. (2026, August 18). Self-Signed Certificates: The 3.3 Million-Domain Census. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/self-signed-certificates-census-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,455,163 certificates)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026