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) | Reveals which authorities you depend on | | Valid-from / valid-to dates | Surfaces expired or soon-to-expire certs before they break things | | Signature algorithm | SHA-1 signatures are deprecated; flag them | | Public-key algorithm and size | RSA vs. ECC — the quantum-relevant detail (Step 4) |
Expiry tracking alone justifies the exercise. An unmonitored certificate that lapses takes a service offline and erodes trust in minutes. But the inventory you build here does double duty: it's also the foundation of a TLS certificate inventory that finds every certificate — the asset register everything else depends on.
Step 3 — Detect deprecated TLS versions (1.0 / 1.1)
Once you've found the endpoints, check which TLS protocol versions each one will negotiate. This is where lingering legacy quietly accumulates.
- TLS 1.0 and TLS 1.1 are deprecated — formally, by RFC 8996 (2021). They carry known weaknesses and should not be in service.
- TLS 1.2 and TLS 1.3 are the current, supported versions. TLS 1.3 is the modern baseline.
A host that still accepts TLS 1.0 or 1.1 is both a security weakness and, increasingly, a compliance problem. The fix is usually a configuration change on a server or load balancer — but only if you know the endpoint exists and what it offers. Note that detecting supported versions is purely a matter of reading what the server advertises during a handshake; it requires no exploitation and no intrusive testing.
See where your organization stands — run a free CipherReady readiness scan and get a cryptographic inventory of your public TLS, certificates, and algorithms in about 3 minutes.
Step 4 — Record public-key types: RSA and ECC are the quantum-vulnerable workhorses
This is the step most certificate audits skip, and it's the one that ties your inventory directly to quantum readiness.
Essentially all public TLS certificates in use today rely on RSA or ECC public keys — and both are broken by Shor's algorithm running on a CRQC. That's not a niche concern; it's the default cryptography protecting nearly every HTTPS connection you operate. For each certificate, record the public-key algorithm (RSA or ECC) and key size so you can see your exposure at a glance.
The migration target is already defined. On August 13, 2024, NIST finalized its first post-quantum standards: FIPS 203 (ML-KEM / Kyber) for key establishment, FIPS 204 (ML-DSA / Dilithium) for signatures, and FIPS 205 (SLH-DSA / SPHINCS+) for hash-based signatures. FIPS 206 (FN-DSA / Falcon) is in progress in 2026, and HQC was selected in March 2025 as a backup KEM. The transition isn't theoretical either: hybrid PQC key exchange (X25519MLKEM768) is already live in Chrome 131 (Nov 2024), Firefox 135 (Feb 2025), OpenSSL 3.5.0 (Apr 2025), and Apple OS v26 — and Cloudflare measured roughly 38% of human HTTPS traffic on hybrid PQC by March 2025.
To be precise about where we are: Google's Willow processor (2025) demonstrated below-threshold error correction — a genuine milestone, not a break of RSA or ECC. The honest posture is "not yet, but prepare now." Knowing exactly which RSA and ECC keys you hold is what makes that preparation actionable, which is why understanding how RSA/ECC certificate risk connects to crypto-agility matters as much as the count itself.
Step 5 — Check HTTP security headers
While you have each endpoint open, capture its HTTP security headers — they round out the external picture of how each host is configured. Useful ones to note include HSTS (HTTP Strict Transport Security), which enforces HTTPS, plus Content-Security-Policy and related controls. These are observable from a plain response and add hardening context to your certificate and protocol findings without any intrusive probing.
What a complete inventory looks like
Put the five steps together and you have a per-host record like this:
| Item | Captured | Quantum-readiness signal | |---|---|---| | Hostnames / subdomains | From DNS + CT logs | Reveals shadow and forgotten assets | | Certificate + expiry | Per endpoint | Operational risk; SHA-1 flag | | TLS versions offered | Per endpoint | TLS 1.0/1.1 deprecated (RFC 8996) | | Public-key type (RSA/ECC) | Per certificate | Quantum-vulnerable; needs PQC migration | | Security headers | Per response | Configuration hardening context |
This is the raw material of a cryptographic inventory — the foundation of any enterprise PQC migration. It's also why inventory is consistently named the first step in closing the post-quantum readiness gap: you cannot scope a migration, satisfy an auditor, or prioritize work until you can see your own attack surface.
The compliance pressure makes this concrete. PCI DSS 4.0 Requirement 12.3.3 mandates a documented cryptographic inventory plus a migration plan for deprecated algorithms (future-dated controls in effect March 31, 2025). DORA (in force January 17, 2025) requires crypto-agility for financial entities, and NIS2 pushes "state-of-the-art" encryption with readiness to upgrade. Each of these starts from the same place: knowing what you run.
Doing it the fast way
You can perform all of the above manually with open-source tooling, and for a handful of domains that's entirely reasonable. The challenge is scale and recurrence — your estate changes weekly, and a one-time spreadsheet goes stale almost immediately.
This is exactly what CipherReady does, for free. It runs a safe, external, metadata-only readiness scan of domains you own or authorize and inventories your public TLS certificates, TLS versions, DNS exposure, public-key algorithms (RSA/ECC), and HTTP security headers. It then produces a CipherReady Readiness Score, an executive PDF report, AI-assisted summaries, and scheduled monitoring so the inventory stays current as your estate shifts. To be clear about scope: CipherReady is not a vulnerability scanner or a pentest — there's no exploitation, no credentials, and no intrusive testing. It's the visibility layer, and the honest first step toward being quantum-ready.
Frequently Asked Questions
Is scanning for certificates and TLS versions intrusive or risky?
No. Everything in this method relies on publicly observable metadata: Certificate Transparency logs, DNS records, the certificate a server presents, the TLS versions it advertises during a handshake, and HTTP response headers. CipherReady's scan is external and metadata-only — no exploitation, no credentials, and no intrusive testing — so it's safe to run against your production estate.
Why do RSA and ECC keys matter for quantum readiness specifically?
Because essentially all public TLS certificates today use RSA or ECC public keys, and both are broken by Shor's algorithm on a cryptographically relevant quantum computer. NIST finalized post-quantum replacements on August 13, 2024 — FIPS 203, 204, and 205 — so the migration target exists. Recording which RSA and ECC keys you hold is what turns "we should migrate someday" into a scoped plan.
Do I really need to remove TLS 1.0 and 1.1?
Yes. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021 and carry known weaknesses; TLS 1.2 and 1.3 are the current versions. Beyond the direct security concern, leaving deprecated protocols in service is increasingly an audit finding under frameworks that expect state-of-the-art encryption. The fix is usually a configuration change — but you have to find the endpoint first.
How long does an external scan take?
For your public-facing estate, an external metadata-only scan returns a cryptographic inventory of your TLS certificates, versions, and algorithms in about 3 minutes — far faster than assembling the same picture by hand, and it can be scheduled to stay current.
See where you stand — in about 3 minutes
You can't fix what you can't find, and a stale spreadsheet won't show you the certificate that's about to expire or the load balancer still speaking TLS 1.0. Get the real picture instead.
Run a free CipherReady readiness scan to inventory your public TLS certificates, TLS versions, DNS exposure, and RSA/ECC keys — and receive a CipherReady Readiness Score and an executive PDF report. The free plan includes 3 scans per month, and you can review paid options on the pricing page when you're ready to add continuous monitoring across your estate. Finding what you have is the first step to being quantum-ready — start there today.