541,960 Let's Encrypt Certificates in View: What a Certificate Field Can and Cannot Tell You
Certificate data is the most structurally reliable material an internet-wide scanner can collect. A TLS handshake returns a signed document with defined fields, in a format that has not changed materially in decades.
That reliability does not extend to the conclusions people draw from it.
The measurement
On 20 October 2026, between 22:33 and 22:37 UTC, queries with sub_type="all" and a page size of one record returned:
| Query | Matched assets |
|---|---|
ssl.cert.issuer.cn="Let's Encrypt" |
541,960 |
http.header.server="nginx" |
284,114,163 |
app="nginx" |
313,028,543 |
The certificate count is three orders of magnitude below the web server counts. That gap is the first thing worth explaining, because it is not a statement about encryption adoption.
Why the certificate count is small
The query matches the issuer common name exactly. Let's Encrypt issues certificates through several intermediate authorities, and the issuer field can be recorded differently depending on how the scanner parses the chain, and on whether the certificate is served directly or through a CDN with its own certificate.
It also counts assets, not certificates and not domains. A single certificate covering multiple names may correspond to many assets or to one, depending on how many of those names were resolved and observed.
So 541,960 is a count of assets whose observed TLS certificate carried that particular issuer field at collection time. It is not the number of Let's Encrypt certificates in existence, and it is not the number of encrypted web services.
The gap is a reminder that certificate-based queries are precise about what is in the certificate and imprecise about what it covers.
What certificate data genuinely supports
Three uses are reliable:
Expiry tracking. A certificate's not-after date is authoritative. An inventory of certificates approaching expiry, derived from observed data, is a valid operational artifact.
Issuer concentration. If an organization discovers that a large fraction of its assets present a certificate from an issuer it does not manage, that is a real finding — usually an unmanaged proxy, a CDN, or an acquired domain.
Unexpected names. The subject alternative names in an observed certificate list hostnames. Where those include names the organization does not recognize, the certificate is a map of infrastructure it may not control.
The third is the most consistently productive. Certificates leak internal naming conventions, staging environments and forgotten subdomains precisely because they must enumerate every name a service answers to, in plaintext, to anyone who connects.
Where certificate inference goes wrong
A common error is treating a certificate issuer as evidence of encryption in transit. A self-signed certificate also encrypts; it simply does not validate. The presence of Let's Encrypt on 541,960 assets says those assets present a publicly trusted certificate, which is a different and narrower statement.
A second error is inferring the certificate's purpose. The same issuer serves personal blogs, internal tools reachable by mistake and enterprise services. Issuer identity carries no information about what is behind the endpoint.
A third, more consequential error: assuming that a valid certificate implies a maintained system. Automated issuance via ACME lowered the cost of getting a certificate to near zero, which means a certificate that renews correctly can coexist with an application that has not been patched in years. The two maintenance processes are independent.
A usable certificate review
For an organization with a substantial estate:
- Collect all certificates presented by assets on your address space and your domains.
- Compare the subject alternative names against your DNS inventory. Investigate any name you cannot account for.
- Group by issuer. Any issuer appearing that your PKI team did not authorize is worth explaining.
- Track expiry separately from patching. Certificate expiry incidents remain common and are entirely preventable.
- Verify that certificates presented on internal services are not from public authorities, which would indicate internal names being disclosed.
Step five is the one most often missed. An internal hostname in a publicly trusted certificate has been published to certificate transparency logs, which means it is discoverable permanently regardless of what happens to the service.
The comparison with header data
The nginx counts in this round — 284 million for the server header, 313 million for the product fingerprint — are a useful contrast. A header is asserted by the server and could be anything; a certificate is cryptographically signed and structurally constrained.
Both are still observations rather than truths about posture. The certificate is harder to falsify, which makes it better evidence, and evidence is not the same as a conclusion.
References
- ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
- Let's Encrypt, certificate transparency documentation.
- CISA, Known Exploited Vulnerabilities Catalog.
