Not a website certificate: EKU, CA flags and missing names
The September 2026 census completed a TLS (Transport Layer Security) handshake with 212,321,916 apex domains and kept the leaf certificate each one presented. A website certificate describes itself in three fields. Its extended key usage (EKU) extension lists serverAuth, the purpose of a TLS server. Its basic constraints say it isn’t a certificate authority. Its subject alternative name (SAN) carries the DNS (Domain Name System) names it answers for.
98.3% of the leaves listed serverAuth. 3,554,612 domains, 1.7% of the base, presented a leaf that breaks at least one of the three: an EKU without serverAuth, a CA certificate served as the leaf, or no DNS name. The scanner’s TLS check accepted none of them. Most of them are self-signed or expired, and their names read like the defaults that servers and hosting panels hand out before anyone installs a real certificate. Another 380,977 leaves had no EKU extension and nothing else out of place, which TLS allows.
The larger group sits inside the serverAuth band. 14,579,830 leaves, 6.9% of the base, list clientAuth beside serverAuth. That is allowed today. Chrome’s root program requires every leaf issued from 15 March 2027 to list serverAuth and nothing else, and the served web is already moving: among leaves issued in August 2026, 0.9% still carried clientAuth.
What a website certificate says about itself
A certificate carries its own statement of what it is for. Three parts of it decide whether it’s a website certificate.
| Field | What a website leaf has | What the census counted |
|---|---|---|
| Extended key usage | The serverAuth purpose, OID 1.3.6.1.5.5.7.3.1 | Every OID in the extension, or none |
| Basic constraints | cA = false | Leaves with cA = true |
| Subject alternative name | At least one DNS name | Leaves with no SAN, or a SAN with no DNS name |
The EKU rules come from RFC 5280 (Request for Comments). When the extension is present, the certificate may be used only for the purposes it lists, so a leaf listing clientAuth (OID 1.3.6.1.5.5.7.3.2) and nothing else isn’t a server certificate. When the extension is absent, RFC 5280 adds no restriction, though it lets an application insist on the extension, so a missing EKU isn’t a fault by itself.
Publicly trusted CAs work to a stricter profile. The CA/Browser Forum’s Baseline Requirements (version 2.3.1, section 7.1.2.7) say a subscriber certificate must have an EKU that includes serverAuth, may add clientAuth, and must not list code signing, email protection or anyExtendedKeyUsage. It must carry a SAN, and its cA flag must be false. Browsers no longer read names from the subject common name (CN): Chrome dropped that fallback in version 58, in 2017, so a leaf with no SAN can’t match any name in Chrome.
Why the EKU matters in 2026
Chrome’s root program wants the certificate hierarchies it trusts to serve TLS server authentication and nothing else. Version 1.8 of its policy, dated 5 February 2026, sets the dates in section 1.3.2. From 15 June 2026 Chrome phases out hierarchies that break the rule, and an intermediate CA disclosed on or after that day must list serverAuth only. From 15 March 2027, every leaf issued beneath a root Chrome trusts must list serverAuth and nothing else.
CAs moved ahead of the leaf date. Let’s Encrypt’s default profile stopped adding clientAuth on 11 February 2026, and the last profile that still offered it closed on 8 July 2026. A leaf issued before such a change keeps its clientAuth until it expires, so the served web carries both kinds for a while. The census reads only the leaf, so it can’t check the intermediates the June date governs.
The served leaves, banded
| Band | Domains | Share of the base | gTLD | ccTLD |
|---|---|---|---|---|
| serverAuth only | 194,180,667 | 91.5% | 91.0% | 92.4% |
| serverAuth with clientAuth | 14,579,830 | 6.9% | 7.2% | 6.2% |
| serverAuth with other purposes | 1,109 | under 0.01% | under 0.01% | under 0.01% |
| No EKU extension | 3,554,399 | 1.7% | 1.8% | 1.4% |
| EKU without serverAuth | 5,911 | under 0.01% | under 0.01% | under 0.01% |
The base is 212,321,916 domains, 144,095,184 under gTLDs and 68,226,732 under ccTLDs, and the five bands add up to it. 18,141,249 leaves, 8.5%, sit outside the serverAuth-only profile Chrome wants from March 2027. No served leaf carried anyExtendedKeyUsage without serverAuth, or an empty EKU. 11,056 serverAuth leaves also listed a purpose the Baseline Requirements forbid in a subscriber certificate, such as code signing or email protection.
The traits overlap. A CA certificate served as the leaf usually has no EKU and no SAN either: 98.4% of them lack an EKU and 97.0% lack a SAN. So the counts in Figure 1 can’t be added together.
Figure 1. Domains whose served leaf has each trait outside the website profile. A leaf can have more than one trait, so the bars overlap.
What the TLS check said about them
The scanner accepted 89.1% of all served leaves. It accepted none of the 3,554,612 leaves outside the profile. It also accepted none of the 3,554,399 with no EKU, a separate count that happens to land close. For the leaves outside the profile, the error the scanner’s library reported was self-signed for 56.0% and expired for 41.9%. The rest failed for other reasons, mostly the chain or the name. Leaves outside the profile mostly lack an EKU too: 89.3% had none.
The leaves carrying clientAuth are a different population. The scanner accepted 45.1% of them. It rejected 28.5% as expired and 21.6% because they didn’t carry the domain’s name. 6,568,910 of the leaves the scanner accepted list clientAuth, 3.5% of every accepted leaf.
Figure 2. The verdict the scanner’s TLS library reported for each group’s domains, one per domain. A leaf that is both self-signed and expired is reported as expired.
No EKU at all
3,554,399 leaves, 1.7% of the base, have no EKU extension. RFC 5280 puts no purpose restriction on such a leaf, so on its own it’s no fault. The Baseline Requirements do have publicly trusted CAs include an EKU, and the scanner accepted none of these leaves. It rejected 58.9% as self-signed and 39.8% as expired.
The issuer field says where most of them came from. The largest single group names no issuer organisation at all. Next come the placeholder names that certificate tools fill in when nobody types one, led by OpenSSL’s Internet Widgits Pty Ltd, and the defaults of hosting companies and control panels.
| Issuer organisation on the leaf | Domains | Share of the no-EKU leaves |
|---|---|---|
| (no issuer organisation) | 1,067,987 | 30.0% |
| Internet Widgits Pty Ltd (OpenSSL’s placeholder) | 441,613 | 12.4% |
| Other placeholder text | 378,358 | 10.6% |
| DreamHost | 237,860 | 6.7% |
| Placeholder: SomeOrganization | 165,422 | 4.7% |
| Placeholder: MyCompany Inc. | 157,985 | 4.4% |
| Placeholder: My Company Ltd | 153,625 | 4.3% |
| ispgateway | 143,384 | 4.0% |
| Plesk (incl. Parallels) | 113,434 | 3.2% |
| Placeholder: Default Company Ltd | 86,553 | 2.4% |
| Every other organisation (24,115 names) | 608,178 | 17.1% |
“Other placeholder text” gathers values such as localhost, XX, MyOrg and unknown. A blank issuer field counts as no issuer organisation. The table names the ten largest values and counts the rest together. An organisation outside the published list of products and placeholders is never named, because many are a single company’s own certificate.
CA certificates served as the leaf
1,680,871 leaves, 0.8% of the base, have cA = true: the server presents a certificate authority’s certificate as its own. 98.4% of them also have no EKU, and 73.8% carry the same common name as issuer and as subject. The scanner accepted none, rejecting 61.3% as self-signed and 38.4% as expired.
One hosting default stands out. 237,860 domains present a CA certificate whose issuer organisation is DreamHost and whose common name is sni.dreamhost.com. The other large groups are OpenSSL’s placeholder organisation, with 402,885, certificates naming no issuer organisation, with 295,055, and ispgateway, with 143,384.
Names only in the common name, or nowhere
2,410,916 leaves, 1.1% of the base, have no SAN and carry their only name in the CN. Chrome hasn’t matched names there since 2017. 1,029,162 more have no name anywhere, and 66,131 have a SAN that holds no DNS name. The scanner’s library still falls back to the CN when a leaf has no SAN, so it’s more lenient than Chrome here, but it accepted none of the 2,410,916 CN-only leaves either.
The names that are there read like defaults. Across the 3,440,078 leaves with no SAN, these were the most common values in the CN.
| Common name | Domains | Share of the leaves with no SAN |
|---|---|---|
| No common name | 1,029,162 | 29.9% |
| plesk | 266,997 | 7.8% |
| localhost | 258,520 | 7.5% |
| sni.dreamhost.com | 237,860 | 6.9% |
| default | 189,533 | 5.5% |
| webslave.ispgateway.de | 143,384 | 4.2% |
| localhost.localdomain | 95,635 | 2.8% |
| sni-support-required-for-valid-ssl | 84,959 | 2.5% |
| The domain’s own name | 80,484 | 2.3% |
| * (a lone asterisk) | 69,278 | 2.0% |
| Every other common name | 984,266 | 28.6% |
Only 80,484 of them, 2.3%, carry the domain’s own name in the CN.
An EKU without serverAuth
5,911 leaves list purposes without serverAuth, and 5,901 of those list clientAuth and nothing else. They are client certificates presented as a server’s own. 96.3% of them name Cloudflare as their issuer organisation. The scanner rejected all of them: 98.6% because their chain didn’t lead to a root it trusts, 56 for the wrong purpose and 25 because they had expired. The census sees that a server presented one, and not why.
clientAuth beside serverAuth, and the 2027 profile
Let’s Encrypt’s served leaves show its February change. Of the 285,508 Let’s Encrypt leaves issued from October 2025 to January 2026 that the census saw, all but 13 carried clientAuth. Of those issued in February, 41.0% did. From March to September, 247 of 117,278,835 did. Leaves from every other issuer fell later and more slowly: 40.2% of January’s carried clientAuth, 13.1% of May’s and 1.7% of July’s, the first full month after Chrome’s 15 June date for intermediates.
Figure 3. Share of served leaves carrying clientAuth beside serverAuth, by the month each leaf was issued.
The month is the certificate’s own start date, and the census sees only leaves still served in September, so the earlier months hold the long-lived ones. Of the 8,012,040 served leaves issued before October 2025, 60.0% carry clientAuth.
By issuer the split is wide. Among Google Trust Services’ served leaves, over 99.9% list serverAuth alone, and among Let’s Encrypt’s, 99.1%. At the other end, clientAuth is on 91.0% of GlobalSign’s, 71.4% of Actalis’s and 99.4% of the leaves issued under Cloudflare’s name. Sectigo, with 4,402,777 leaves carrying clientAuth, and GoDaddy, with 3,324,066, hold the most by count.
Figure 4. Each issuer’s served leaves by EKU, for the ten issuers serving the most domains.
These leaves follow the rules they were issued under, and they stay valid until they expire. The 2027 date governs what a CA may issue from then on.
The servers behind them
The leaves outside the profile come mostly from general-purpose web servers. The nginx server answers for 50.3% of them against 15.5% of all served leaves, and Apache for 21.5% against 13.2%. Platforms that issue certificates for their customers barely appear. Cloudflare’s server header is on 20.5% of all served leaves and on 106 of these 3,554,612. Squarespace’s is on 4.4% of all served leaves and on 4 of these.
Figure 5. Server header families: share of every served leaf against share of the leaves outside the profile.
By top-level domain
| TLD | Base | No EKU | CA leaf | No SAN | Outside the profile | clientAuth beside serverAuth |
|---|---|---|---|---|---|---|
| .com | 99,672,786 | 1.5% | 0.7% | 1.4% | 1.5% | 6.7% |
| .de | 8,963,282 | 1.6% | 1.0% | 1.9% | 1.9% | 8.3% |
| .org | 6,717,905 | 1.7% | 1.2% | 1.6% | 1.6% | 6.2% |
| .xyz | 6,377,394 | 3.5% | 0.6% | 3.5% | 3.5% | 19.6% |
| .net | 6,019,123 | 2.0% | 1.1% | 1.9% | 2.0% | 8.1% |
| .uk | 5,347,256 | 0.8% | 0.3% | 0.7% | 0.7% | 3.9% |
| .ru | 3,275,238 | 3.9% | 1.6% | 3.9% | 3.9% | 10.8% |
| .br | 3,185,778 | 0.2% | 0.1% | 0.2% | 0.2% | 4.2% |
| .nl | 3,175,968 | 2.0% | 0.4% | 2.5% | 2.6% | 3.6% |
| .cn | 3,173,377 | 3.6% | 0.7% | 3.9% | 4.1% | 4.9% |
| .fr | 2,518,282 | 0.6% | 0.2% | 0.5% | 0.5% | 3.1% |
| .top | 2,512,255 | 5.5% | 4.6% | 5.4% | 5.6% | 2.1% |
The table lists the twelve TLDs with the largest base, and each share is of that TLD’s own base. Under gTLDs 1.8% of leaves are outside the profile, and under ccTLDs 1.4%. Among the twelve, the share runs from 0.2% in .br to 5.6% in .top, where 4.6% of leaves are CA certificates. In .xyz, 19.6% of leaves carry clientAuth, about three times the 6.7% in .com.
What the census can and can’t see
- The scan connected to each domain’s apex once, with that name in the TLS server name indication field, and kept the leaf the server chose to present. It didn’t visit www or any other subdomain, and it didn’t read the intermediate certificates.
- Bands come from the OID strings in the EKU extension as Node’s TLS library reports them, never from names. A leaf whose EKU lists serverAuth among other purposes counts as serverAuth. The census saw 129 distinct EKU lists.
- “Accepted” means the scanner’s TLS library verified the chain to its bundled roots and matched the domain’s name. When a leaf has no DNS name in a SAN, that library falls back to the CN and Chrome doesn’t. It accepted none of the CN-only leaves, so no figure here depends on the difference.
- Each rejected domain carries one error, the one the library reported. A leaf can have several faults, and a self-signed leaf that has also expired is reported as expired. The certificate check flags 3,018,232 of the leaves outside the profile as self-signed, while the library reported 1,988,816 of them that way.
- The month of issue is the certificate’s own start date. The census sees only leaves still being served in September 2026.
- Where a domain was scanned twice, one row counts: graded before dead before unreachable before indeterminate, then the later pass. gTLD and ccTLD follow the IANA (Internet Assigned Numbers Authority) root zone database’s type column.
- CAs are grouped by the organisation on the certificate, with older brands folded in: Starfield under GoDaddy, Comodo under Sectigo, and GeoTrust, Thawte and RapidSSL under DigiCert. The Let’s Encrypt group includes 852 leaves from its staging service, which browsers don’t trust, and 4 whose issuer only resembles its name. Other issuer names and common names appear only when they are a product’s own default or a tool’s placeholder text.
See your own
The free scan connects to your apex the same way the census did and reports whether the certificate it was handed is valid and trusted for your domain. The TLS pillar explains each warning.
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.