Every certificate you've ever issued is sitting in a public log right now, and it was never meant to protect you from what happens next.

Certificate Transparency was built to catch rogue CAs. Instead, it accidentally became the best free recon tool in an attacker's toolkit. Nobody advertises that part.

1. The vulnerability hiding inside a "security feature"

Since 2018, every publicly trusted SSL/TLS certificate has to be logged in a Certificate Transparency (CT) log before browsers will trust it. That's a good rule — it stops CAs from silently minting fraudulent certs for domains they don't control.

But CT logs are public, permanent, and searchable. Tools like crt.sh let anyone pull every subdomain a company has ever issued a cert for — staging., internal-vpn., old-admin-panel., dev-api-v2. — the exact naming conventions security teams use internally, handed over for free.

This is step one of nearly every serious subdomain enumeration workflow. Red teamers use it. So do real attackers. You don't need to scan a company's infrastructure anymore — you just read their certificate history.

Layer on top of that the rest of the traditional trust stack:

  • CA dependency — your domain's security is only as strong as the weakest of the 100+ CAs your browser trusts by default, any one of which can issue a valid cert for your name if compromised or coerced.
  • Centralized root zone — every .com, .org, and .net ultimately resolves through a root system governed by ICANN and a small number of root server operators.
  • Single point of policy failure — a court order, a government request, or a registry-level dispute can affect resolution for an entire TLD, not just one domain.

None of this requires a hack. It's all working exactly as designed. That's the uncomfortable part.

2. What happens if the root itself is disrupted

Ask yourself a question most people never ask: what actually happens if ICANN's root zone management is disrupted, disputed, or politically pressured?

The honest answer is: a lot, and none of it is decided by you, your registrar, or the people actually running the affected sites. Domain seizures, TLD-level takedowns, and registry disputes are not hypothetical — they've happened. The naming layer of the internet has exactly one governing hierarchy, and everyone using a .com is a tenant in someone else's building. It's the same single-hierarchy problem that shows up whenever governments try to bolt identity systems like voter ID onto infrastructure nobody outside a small governing body actually controls.

3. How Handshake changes the actual attack surface

Handshake doesn't try to patch Certificate Transparency or add another layer of trust brokers. It removes the thing CT logs were compensating for in the first place: a centralized certificate authority system that has to be watched.

Two structural differences do the real work:

No decentralized root-zone bottleneck. Top-level names on Handshake are owned directly by whoever won them in a decentralized, blockchain-based auction — not leased from a central registry that can be pressured, subpoenaed, or politically overridden. There's no single root operator whose disruption cascades into every domain beneath it.

DANE instead of the CA cartel. DNS-Based Authentication of Named Entities (DANE) lets a domain publish its own TLSA records directly in the (cryptographically verifiable) zone, binding a certificate to the domain itself. You no longer need to trust a rotating cast of 100+ certificate authorities — the domain owner is the authority. That also means there's no equivalent public CT log broadcasting your subdomain map to anyone who runs a query. The recon surface that CT logs hand attackers on traditional DNS simply doesn't exist in the same form.

This isn't a claim that Handshake is "unhackable." It's a claim that the specific, well-documented attack surface created by CA dependency and public certificate logging is architecturally different when the domain owner controls their own authentication chain.

4. The line worth screenshotting

Traditional DNS makes your security infrastructure part of your attack surface. Handshake makes your domain its own root of trust.

Or put another way: on traditional DNS, the system built to verify you is also the system that maps you for anyone who's looking. On Handshake, there's no third party in the middle to map.

5. Where this fits in the bigger picture

This is one piece of a larger shift in how naming and trust work online — the same shift covered in The Iceberg of the Internet series, and one that extends beyond human domains into machine-to-machine trust, like AI agent identity on Handshake.

To actually resolve Handshake domains and see DANE-verified sites for yourself, the only tools we recommend are SkyInclude Browser and the DANE HNS Browser — both built to handle Handshake resolution correctly out of the box.

Curious how deep this rabbit hole goes? learnhns.com is where we break down the entire stack, one lesson at a time.

NIHON — Handshake Infrastructure & Web3 Identity