TLS & Certificates
How to Find Every TLS Certificate and Deprecated Protocol Across Your Domains (2026)
Locate every TLS certificate, TLS 1.0/1.1 endpoint, and RSA/ECC key across your domains with a safe, external metadata-only scan. Free in ~3 minutes.
How to Find Every TLS Certificate and Deprecated Protocol Across Your Domains (2026) You can't fix what you can't find. The most common gaps in any internet facing estate aren't exotic zero days — they're a forgotten certificate on a staging subdomain, an old load balancer still negotiating TLS 1.0, and the simple fact that nearly every public TLS certificate today is signed with RSA or ECC keys that a future quantum computer will break. This guide walks through a practical, non intrusive method for locating every certificate, every deprecated protocol version, and every quantum vulnerable key type across your domains — and explains why each item matters for your post quantum readiness. Why visibility is the hard part Certificates and TLS endpoints multiply faster than anyone tracks them. Marketing spins up a subdomain, a vendor provisions an integration host, an engineer stands up a temporary environment, and each one gets its own certificate. Over months and years, the live picture drifts away from whatever spreadsheet someone last maintained. These shadow and forgotten certificates are exactly where the risk hides: an expired cert that breaks a customer flow, a TLS 1.0 endpoint that fails a compliance audit, or an RSA key that becomes a "harvest now, decrypt later" target. That last point is the one most teams underestimate. Under a harvest now decrypt later (HNDL) model, adversaries record encrypted traffic and long lived data today to decrypt later, once a cryptographically relevant quantum computer (CRQC) exists — and guidance from DHS, NCSC, ENISA, and ACSC is built on this premise. The Global Risk Institute's 2025 assessment (Dr. Michele Mosca) puts the median CRQC estimate around 2029–2032, with roughly a 34% probability by 2030. Mosca's theorem frames the urgency plainly: if your migration time (X) plus your data's shelf life (Y) exceeds the time until a CRQC arrives (Z), you are already at risk. None of that planning is possible until you know what cryptography you actually run — which makes inventory the unavoidable first step. The good news: most of what you need to find is publicly observable from the outside, using metadata only — no credentials, no exploitation, no intrusive testing. Here's how to do it. Step 1 — Enumerate your domains and subdomains You can't inventory certificates on hosts you don't know exist, so start by building the widest possible list of names you own or authorize. Start from your registered domains and any brands, acquisitions, or regional variants. Mine Certificate Transparency (CT) logs. Every publicly trusted certificate issued for your domains is logged to public CT logs. This is one of the best sources for discovering subdomains you forgot about, because the certificate itself reveals the hostname. Pull DNS records (A, AAAA, CNAME, MX) to map live hosts and exposure. Cross check against asset lists from IT, cloud consoles, and any existing CMDB. The output of this step is a candidate list of internet facing hostnames. Expect surprises — the gap between "domains we think we have" and "names with live certificates" is usually where the forgotten estate lives. Step 2 — Locate certificates and check expiry For each live host, retrieve the certificate presented on its TLS endpoint and record the fields that matter operationally and cryptographically: | Field to capture | Why it matters | | | | | Subject / SAN hostnames | Confirms coverage and finds names you didn't expect | | Issuer (CA) | Reveal