Your staging site is public, and Certificate Transparency just told everyone where

You spun up staging.yoursite.com to test a release. You gave it a TLS certificate so the browser would stop complaining. You shipped, moved on, and forgot it was there. It's still running - older code, debug logging on, maybe the default admin password, definitely no WAF - and it's reachable from the open internet. The only thing missing was a way for a stranger to find it. Certificate Transparency handed them one.

Every time a certificate authority issues an HTTPS certificate, it's required to publish that certificate to public, append-only Certificate Transparency logs. The system exists for a good reason - it lets anyone detect mis-issued certificates - but it has a side effect: the moment you put a cert on staging.yoursite.com, the hostname staging.yoursite.com is permanently published to a public ledger that anyone can search. Subdomain enumeration used to take active scanning. Now it's a single query to a CT log mirror like crt.sh.

Why a forgotten subdomain is a real finding

Having subdomains isn't a problem - every company does. The problem is a subdomain whose name signals it was never meant to be hardened, that's still live and serving content to the public. staging, dev, uat, qa, test, admin, jenkins, gitlab, vpn - these are the environments where the rules are relaxed: debug mode on, sample data that's actually real data, last quarter's unpatched code, basic-auth with a password the team shares in Slack. Production gets the attention; staging gets forgotten. An attacker who can't find a hole in your hardened production site will happily pivot to the dev box that mirrors it.

Find them before someone else does, then lock them

You can't un-publish a certificate from the CT logs - that's by design. What you can control is whether those hostnames lead anywhere a stranger can reach.

staging.yoursite.com  →  200 OK, public, debug on
dev.yoursite.com      →  200 OK, public, old code
jenkins.yoursite.com  →  200 OK, public login page

Audit what Certificate Transparency says about your domain - the same query an attacker runs - and for every non-production host, decide: does this need to exist, and if so, why is it reachable from the internet? Put it behind an IP allowlist, a VPN, or real authentication, or take it down. The ones you forgot are exactly the ones that matter.

This is a passive check with one important note: SurfaceCheckr never touches your site to enumerate - it reads the public CT logs about your domain (an external lookup), then, for each subdomain whose name flags a non-production environment, confirms it still resolves in DNS and actually returns a 200 before flagging it. That three-way gate - risky name, live in DNS, serving content - is what keeps dead, long-expired certificate entries from raising false alarms. It tells you which forgotten doors are still standing open, which is the thing you can only see by looking from outside.