up:: Classical Cryptography MOC

What Attackers Learn From Your TLS Certificates

Certificate reconnaissance is the large-scale collection of TLS certificates, from public certificate logs and by scanning the internet directly, to learn what software, devices, and cryptography sit behind an organization’s IP addresses. Every server hands its certificate to anyone who opens a TLS connection, before any login and as a required step of the protocol, so the certificate is public by design and reading one leaves no trace. The certificate describes the system holding it: the hostnames it answers for, the authority that issued it, when it was installed and when it expires, and the exact public-key algorithm and key size it runs. Collected at scale, those descriptions turn a range of anonymous IP addresses into a named, versioned, sortable inventory of somebody else’s estate.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §4.4.2, August 2018, RFC 8446.

The short version:

1. A certificate is given away to anyone who connects, before authentication, because the protocol requires it. Collecting one is reading what the server publishes about itself.
2. The fields carry the hostnames a system answers for, the authority that issued it, the dates it was installed and expires, and the cryptographic algorithm and key size in use.
3. The FBI stated the purpose plainly in an August 2026 seizure affidavit against a Chinese state-sponsored scanning platform: TLS certificates “can provide an attacker information on the software or device type behind an IP address.”
4. It is target selection. A collected certificate contains a public key and moves an attacker no distance at all toward reading traffic, so certificate collection stands as evidence of reconnaissance rather than of harvest now, decrypt later.
5. The post-quantum consequence is that every certificate publishes its own algorithm, so which of an organization’s public-facing systems still depend on RSA or elliptic-curve cryptography is externally observable, at scale, for free, and over time.

Think of the brass plate beside the door of every building in a city. It names the architect, the year of the last renovation, the date the elevator inspection expires, and the make and model of the lock. None of it is secret, none of it opens anything, and anyone walking past can read it. Now picture somebody who has photographed every plate in the city and keeps the collection in a database. When a lock manufacturer announces a defect in one model on a Tuesday, that person doesn’t go walking the streets looking for the model. They run a query, and by Thursday they have the addresses.

What does a TLS certificate tell someone who never logs in?

A certificate is a structured public document, and its fields are defined by RFC 5280. The server presents it during the handshake as the Certificate message, which in TLS 1.3 arrives immediately after the key exchange and before the client has proven anything about itself. Anyone who can complete a TCP connection to the port gets a copy. TLS 1.3 encrypts that message, which changes who can collect it rather than whether it can be collected: under TLS 1.2 a passive observer read certificates off traffic that was never addressed to them, and under TLS 1.3 the collector opens a connection of their own and receives the certificate as any client would.

Source: D. Cooper et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, §4.1, May 2008, RFC 5280.

Certificate field	What it says about the system behind it
Subject and Subject Alternative Name	Every hostname the system answers for, which exposes internal naming conventions, subdomain structure, and sometimes administrative email addresses and organizational unit names
Issuer	Whether a public certificate authority signed it, an internal CA did, or the certificate is a vendor’s factory default, in which case the issuer string usually names the product
Validity (notBefore, notAfter)	When the system was last provisioned, how long the operator’s renewal cycle runs, when key material is next scheduled to move, and whether the host has been left unattended
Subject Public Key Info	The public-key algorithm and its parameters, so RSA-2048, P-256, or ML-DSA-65 is stated outright
Signature Algorithm	The hash and signature algorithm the issuing CA used, which characterizes the issuing infrastructure as well as the leaf
Serial Number and extensions	Issuance patterns across a CA, plus key usage, extended key usage, and revocation endpoints that point at further infrastructure

Two of these rows do more work than the rest. The Subject Alternative Name is the one that maps an organization, because a single certificate on a load balancer routinely lists dozens of internal service names that appear nowhere in public DNS. The Issuer is the one that identifies a product, because network appliances ship with self-signed certificates carrying the vendor’s own strings, and a VPN concentrator that has never had a certificate installed announces its make in the field meant to establish its identity.

Source: D. Cooper et al., RFC 5280, §4.2.1.6 (Subject Alternative Name) and §4.1.2.7 (Subject Public Key Info), RFC 5280.

Why do attackers collect certificates at scale?

The clearest available answer comes from a sworn federal affidavit rather than from a vendor report. On 24 August 2026, an FBI special agent applied for warrants to seize three domains operating a Chinese state-sponsored scanning platform called QScan and an obfuscation network called QTRouter, both built and run by a group the Bureau calls QTFY, working for a private company in Nanjing whose payments from the PRC Ministry of State Security are part of the government’s evidence.

Paragraph 33 of that affidavit describes what the platform actually did: QScan “processed a variety of task queues, including webpage scraping, Trasport [sic] Layer Security (TLS) certificate collection, subdomain enumeration, and penetration testing.” The footnote attached to that sentence defines the term for the court, and in doing so states the operational purpose:

“A TLS Certificate is a digital file issued by a trusted third party that verifies a website’s identity and enables secure, encrypted communication. TLS certificates can provide an attacker information on the software or device type behind an IP address.”

Source: Affidavit in Support of Applications for Seizure Warrants, United States District Court for the Southern District of California, sworn 24 August 2026, ¶33 and n.2, DOJ court document.

Three details in the surrounding paragraphs give the practice its proper scale and its proper category.

1. Certificate collection sat in a reconnaissance family, not a cryptographic one. It shares its sentence with subdomain enumeration and content-management-system plugin detection, which are both unambiguously about finding out what a target runs.
2. The volume was indiscriminate. The affidavit records that on a single day in 2024, QScan processed over two million scanning and exploitation tasks. This was internet-wide collection into which government networks fell along with hospitals, telecommunications providers, power companies, financial institutions, and defense contractors.
3. The reconnaissance fed an exploitation database. QScan carried “a database of over 200 proof-of-concept exploits written in Python,” and the affidavit says the platform “was designed for large scale deployment.”

Source: Affidavit, ¶¶13-15 and ¶33, DOJ court document. See also Justice Department, “Justice Department and FBI Seize Platforms Operated and Used by China State-Sponsored Hackers to Target U.S. Critical Infrastructure,” 26 August 2026, DOJ press release.

A note on reading that case accurately. The Justice Department’s original announcement said several federal agencies “were victims of attacks” and was revised days later to say the same agencies were “among the targets of QTFY,” which is the wording the affidavit itself uses. The affidavit’s own NASA example failed: QTFY actors attempted an exploit against a NASA server on 10 and 12 August 2019, and the footnote records that “because NASA had applied a security patch to address this vulnerability prior to the attempted exploitation, the attempt was not successful.”

Source: Affidavit, ¶14 and ¶16 n.1, DOJ court document.

Where do collected certificates come from?

Two sources, carrying different things, which is the reason a scanning platform is worth building at all.

Public certificate logs. Certificate Transparency defines public, append-only logs that record every certificate a certificate authority issues, and browser policy is what makes logging universal in practice: Google’s Chrome CT policy states that “all publicly-trusted TLS certificates are required to be CT Compliant to successfully validate.” The result is that essentially every publicly-trusted certificate sits in an open archive, structured, searchable, and historical. Collecting those is a download, done at arm’s length from the target and available to anyone who wants the archive.

Sources: B. Laurie, A. Langley, E. Kasper, “Certificate Transparency,” RFC 6962, June 2013, RFC 6962. Google, “Chrome Certificate Transparency Policy,” Chrome CT Policy.

Direct scanning. What the logs cannot show is the larger and more interesting half:

1. Self-signed and factory-default certificates on appliances, which never touch a public CA and therefore never appear in a transparency log, while carrying the vendor strings that identify the product.
2. Internal CA certificates issued by an organization’s own PKI, which are trusted only inside the estate and are invisible publicly.
3. Services on non-web ports, since a mail server, a database, a management interface, and a VPN gateway all present certificates.
4. The live binding between a certificate and an address, because a log entry proves a certificate was issued while a scan proves it is being served right now, at a specific IP, on a specific port.
5. Expired certificates still in service, which a log records as issued years ago and a scan finds still answering.

That last one is worth pausing on, because an expired certificate that a server is still presenting is one of the most reliable indicators in external reconnaissance. Certificates expire on a schedule everybody knows in advance. A host serving an expired one is a host whose owner is not watching it.

How does a corpus of certificates become a target list?

The chain runs in five moves, and the QTFY case shows all of them.

1. Collect continuously. Sweep address space and public logs, and store what each address presents along with when it presented it.
2. Identify the product. Resolve the issuer and subject strings, the key parameters, and the extension profile to a vendor and often a firmware generation, because appliance defaults are consistent across installations.
3. Enrich the map. Fold in subdomain enumeration and content-management plugin detection, which is precisely the combination of queues the affidavit lists, until each address carries a description rather than a number.
4. Wait for a vulnerability. The inventory sits until a vendor publishes an advisory or a proof-of-concept lands in the exploit database.
5. Query and exploit. Select every stored host matching the affected product and run the exploit against the list.

The compressed timeline is what makes step 5 worth all the effort in steps 1 through 4. Check Point published CVE-2024-24919 on 28 May 2024, an information-disclosure flaw affecting Check Point Quantum Gateway, Spark Gateway and CloudGuard Network, described by the vendor as “potentially allowing an attacker to read certain information on Check Point Security Gateways once connected to the internet and enabled with remote Access VPN or Mobile Access Software Blades.” The affidavit records that QTFY actors exploited it successfully “several days after the CVE was published,” and that they used it to steal “sensitive information including server configuration files and user account details from over 300 organizations in the United States.”

Source: Check Point Software Technologies Ltd. (CNA), CVE-2024-24919, published 28 May 2024, CVE record. Affidavit, ¶34, DOJ court document.

An organization scanning its own estate from scratch after that advisory would still have been enumerating hosts while an organization holding a pre-built inventory was already reading configuration files. The same pattern appears earlier in the same document with CVE-2019-11510, an unauthenticated arbitrary-file-read flaw in Pulse Secure Pulse Connect Secure that let a remote attacker recover legitimate users’ credentials, used against both NASA and a hospital system in separate incidents months apart.

Source: MITRE, CVE-2019-11510, published 8 May 2019, CVE record. Affidavit, ¶¶16-17 and ¶22, DOJ court document.

Both of those flaws sat in a VPN gateway, which is a device whose entire function is to terminate TLS at the edge of a network, and which therefore always presents a certificate to anybody who asks.

Is collecting certificates the same as harvest now, decrypt later?

No, and the two get conflated often enough that the distinction is worth stating precisely.

Harvest now, decrypt later requires recorded ciphertext. An adversary has to sit in a position where encrypted traffic passes, capture it, and store it until a cryptographically relevant quantum computer can recover the keys. The stored asset is the traffic.

A certificate is not that asset. It carries a public key, which is the thing that would eventually be broken rather than the thing that would be read. Even granting a future quantum computer, breaking the key inside a certificate does not recover past sessions protected by any modern cipher suite, because forward secrecy derives each session’s keys from an ephemeral Diffie-Hellman exchange that never appears in the certificate at all. TLS 1.3 removed static RSA key transport entirely and requires an ephemeral exchange for every handshake, so what breaking a certificate key buys against a current-generation server is the ability to impersonate it going forward.

Source: E. Rescorla, RFC 8446, §1.2 (removal of static RSA and Diffie-Hellman cipher suites), RFC 8446.

There is a genuine historical exception, and it is narrow. Under the RSA key-transport cipher suites available in TLS 1.2 and earlier, the client encrypted the premaster secret to the public key in the server’s certificate, so an adversary holding both a recorded session and the ability to break that key could recover the session. Traffic of that kind, recorded before ephemeral key exchange became universal, is the one case where a certificate genuinely is an HNDL asset. It is a shrinking archive rather than a reason to run a scanning platform.

The accurate quantum-era framing for certificate collection is targeting rather than decryption. Knowing which systems will still be running classical algorithms years from now tells an adversary where a future capability pays off, and therefore where recording traffic is worth the storage today. The collection is what makes the harvesting selective. For who is plausibly recording that traffic, see Store-Now-Decrypt-Later Actor Landscape, and for the two distinct kinds of quantum exposure, see HNDL vs Non-HNDL.

What does a certificate reveal about your post-quantum posture?

This is where certificate reconnaissance stops being general security hygiene and becomes specific to the quantum transition.

RFC 5280 requires every certificate to carry a Subject Public Key Info field naming the algorithm and its parameters, and a signature algorithm identifier naming what the issuer used. Those fields exist so that a client can validate the certificate, and they are not optional, obscured, or negotiable. A server running RSA-2048 says so. A server running P-256 says so. A server running ML-DSA says so.

Source: D. Cooper et al., RFC 5280, §4.1.1.2 and §4.1.2.7, RFC 5280.

The consequence follows directly. Any external party can assemble a partial cryptographic inventory of any organization’s public-facing estate without touching it, and can watch that inventory change over time, because Certificate Transparency logs are historical and scanning is repeatable. Migration progress on the public perimeter is a measurable, external quantity. Which of an organization’s internet-facing systems still depend on algorithms that Shor’s algorithm breaks is answerable from the outside, by anyone, at no cost.

Two limits bound what an external view can actually tell anyone.

The external view is partial. It sees TLS on reachable ports. It does not see code signing, database key wrapping, internal service-to-service authentication that never crosses the perimeter, firmware verification, or the cryptographic inventory of anything not exposed. A certificate scan is not a substitute for cryptographic discovery, and treating it as one produces an inventory that is confidently wrong about most of an estate.

The asymmetry runs the wrong way. Many organizations have a less complete picture of their own perimeter than an external scanner does, because certificates get issued by teams that leave, on hosts that were never inventoried, for services nobody has owned in years. That is the condition The Undocumented Estate describes, and the external view is one of the few places where the outside party’s map is genuinely better than the inside party’s.

Has this happened before?

Reading a system by what it publishes about itself, rather than by breaking what it protects, is one of the oldest disciplines in signals intelligence, and GCHQ has published its own account of running it against the German Air Force’s BROWN network during the Second World War.

GCHQ’s framing of the discipline is direct: “Traffic Analysis is fundamentally the study of how adversaries use the communications available to them.” The agency is blunt about how much of its reputation rests on the cryptanalysis instead: readers know “Enigma and Tunny for example, but won’t know much about the TA which enabled both those cryptanalytic successes. Yet military Sigint in the 20th century, the First World War, the Second World War, the Cold War, was built on a foundation of TA, without which, successful Sigint would not have been possible.”

What the BROWN analysts built was a catalog. Their central product, the Daily Story, “tabulated on a daily basis the activity of each group within the network, listed each active station, its location, the callsigns used (both the underlying basic callsign and its encrypted version, which changed daily), the frequencies, the times of activity (both scheduled and unscheduled), details of traffic passed, and the names and identifiers of operators.”

Five standing indexes sat around it:

1. A personality index.
2. A separate “Hotel Register,” which indexed individuals at each location, since operators moved around the network on detached duty.
3. A callsign book, which predicted the daily changing encryption of the basic callsigns.
4. A Frequency Index, which recorded frequency usage across the network.
5. A regimental list of all identified personnel, sorted as far as possible into companies.

GCHQ names the finest-grained layer explicitly: “at the heart of all of them is the individual operator, and the individual operator’s idiosyncrasies can be as valuable to the analyst as the result of direction finding, the radio-fingerprinting of his receiver, or the analysis of the callsigns used on the network.”

Source: GCHQ, “The BROWN Story,” GCHQ historical account.

A corpus of TLS certificates is the same artifact, assembled by a scanner instead of by listeners. Each entry records a station, its address, the identifiers it broadcasts, when it is active, when it changed, and what equipment is behind it. The Germans changed their ciphers and their callsigns and the catalog survived both, because the catalog was never built from the content. Certificate collection has the same property, which is why an organization can rotate every key it owns and remain exactly as legible to a scanner the following morning.

What are the common misconceptions about certificate reconnaissance?

“Somebody collecting our certificates means they’re preparing to decrypt our traffic.” Collecting a certificate is collecting a public key and a description. It advances decryption by nothing at all. The QTFY affidavit puts the collection queue beside subdomain enumeration, and its own footnote gives fingerprinting as the purpose.

“Certificate collection is a breach.” The server hands the certificate to every client that connects, as a required step of the TLS handshake. What the scanner sees is what the protocol is designed to publish.

“Keeping certificates out of Certificate Transparency keeps them private.” A CT-enforcing browser requires valid Signed Certificate Timestamps before it will validate a publicly-issued certificate, so a certificate kept out of the logs is a certificate that fails in Chrome. Certificates that genuinely never reach the logs, meaning internal-CA and self-signed ones, are found by scanning instead.

“This only matters for public web servers.” Mail servers, VPN concentrators, management interfaces, load balancers, printers, and industrial devices all terminate TLS and all present certificates. The two vulnerabilities QTFY used most in the affidavit were both in remote-access gateways.

“A self-signed certificate gives away less than a CA-issued one.” It frequently gives away more. A factory-default certificate names its vendor in the issuer field, which turns an anonymous address into a specific product, and an unreplaced default also indicates the device was deployed without the installer touching its certificate configuration.

“An expired certificate is a low-severity finding.” As a matter of reconnaissance value it is one of the highest-quality indicators available externally, because certificates expire on a published schedule and a host still serving an expired one is a host nobody is maintaining.

Questions people ask

Can an organization stop attackers from reading its certificates? No. Presenting the certificate is how TLS establishes server identity, so any client completing a handshake receives it. That is the protocol working correctly rather than a misconfiguration, and it is why certificate contents are treated as public information in every threat model that handles them properly.

Does Certificate Transparency make this problem worse? CT publishes certificates that were already presented publicly to every visitor, and it exists to make CA mis-issuance detectable, which is a security property with no substitute. It does make bulk collection cheaper and gives historical depth that scanning alone lacks. Both things are true, and the design tradeoff was made deliberately in RFC 6962.

Does a wildcard certificate expose less than one listing many names? A wildcard replaces an enumerated list of hostnames with a pattern, so it publishes fewer specific names. It also tells a reader that a single key protects an entire namespace, which is information of its own about how the estate is structured and where a compromise would reach. Neither shape is silent.

Does migrating to post-quantum algorithms change what a scanner can see? It changes the answer, not the visibility. A certificate carrying ML-DSA announces ML-DSA in exactly the same field that a certificate carrying RSA announces RSA. External observers can therefore measure migration progress across the public perimeter over time, which is a property of the certificate format rather than of any particular algorithm.

Is scanning for certificates illegal for the party doing it? The QTFY seizure warrants were not sought on the basis of the scanning itself. The affidavit’s stated grounds were money laundering under 18 U.S.C. §§ 1956(h) and 1956(a)(2)(A) and damage to a protected computer under § 1030(a)(5)(A), and the money-laundering theory rests on two domain registration payments of $85.70and$43.83 sent from China into United States registrars. The exploitation that the reconnaissance enabled is what carried the criminal exposure.

Source: Affidavit, ¶2 and ¶¶37-39, DOJ court document.

Does using an internal certificate authority keep certificates out of public view? It keeps them out of Certificate Transparency, because internal CAs do not log to public logs. It does not keep them out of a scan of any host that is reachable, and internal certificates typically carry richer internal naming than public ones do, which is why the scanning half of the collection exists.

What did the QTFY case actually establish about TLS certificates? It put a sworn federal statement of purpose on the record: TLS certificates “can provide an attacker information on the software or device type behind an IP address,” and a Chinese state-sponsored platform ran a dedicated task queue collecting them alongside subdomain enumeration and plugin detection, at a volume exceeding two million tasks in a single day in 2024. The document describes reconnaissance, and it describes no interception, recording, or storage of encrypted traffic anywhere.

How far back does this kind of collection go? The affidavit places QTFY’s infrastructure in use since at least 2018 and its targeting through June 2026, which is roughly an 8-year window for a single group’s platform. Certificate scanning as a public research practice is older still, and predates any of the case’s activity.

Source: Affidavit, ¶14, DOJ court document.

Go deeper

The certificate itself, field by field, is X.509 Certificate. The public logging system is Certificate Transparency, and the trust structure behind both is Public Key Infrastructure (PKI) and Certificate Authority. On the quantum side, HNDL vs Non-HNDL separates the two exposure types this note distinguishes between, Quantum-Vulnerable Algorithm lists what actually breaks, and Certificate Lifecycle Management for PQC covers what happens to certificates during the migration. For the difference between an outside view and a real inventory, see Cryptographic Discovery and The Undocumented Estate.

---

Everything here is the map, given freely. When your team needs the outside view of your estate turned into a real cryptographic inventory and a migration sequence, that’s the work I do.

Last verified 2026-09-10 · Maintained by Addie LaMarr, LaMarr Labs.