Give an internal-sounding service a hard-to-guess hostname - vault-x7, backup-internal - put it behind a TLS certificate, and feel safe because nobody could guess the name. They do not have to guess. The moment a publicly-trusted certificate is issued for that name, it is written into public, append-only logs that anyone can search in seconds. Certificate Transparency is a genuinely good security system, and a direct consequence of it is that a secret subdomain is a contradiction in terms.
//What Certificate Transparency Is
Certificate Transparency, defined in RFC 6962, is a network of public, append-only logs built on Merkle trees. When a certificate authority issues a certificate, it submits it to these logs and gets back a signed proof of inclusion. The purpose is excellent: it makes mis-issuance visible. If a CA is tricked or compromised into issuing a certificate for your domain, it shows up in a public log where you (or a monitor) can catch it. CT is one of the quiet reasons the web PKI is far more trustworthy than it was a decade ago.
The important nuance - and the thing most explanations get wrong - is that CT is not mandatory because the RFC says so. RFC 6962 is an experimental mechanism that compels nothing on its own. CT is mandatory in practice because the major browsers made it a condition of trust: Chrome has required CT compliance for all newly issued publicly-trusted certificates since 30 April 2018, and Apple's platforms require it too. A certificate that is not logged is not trusted, so the padlock and the public record come together. You cannot have one without the other.
//The Side Effect: Every Name You Certify Is Public
Because every issued certificate carries the hostnames it is valid for, and every certificate is logged, the logs are a searchable directory of an organisation's hostnames. A single query to a log-search service like crt.sh returns every subdomain anyone has ever obtained a public certificate for. This is not an exotic attack - it is a standard first step in reconnaissance, listed in the OWASP testing guide, which gives the literal crt.sh query and notes it surfaces hostnames that plain DNS enumeration would miss. Your ldap-admin.example.com, stood up quietly last year with a Let's Encrypt cert, has been in a public index ever since.
//Wildcards: a Real but Partial Fix
A wildcard certificate for *.example.com is logged as exactly that - the wildcard - so the specific hostnames behind it never enter CT. That is a real reduction in what the logs leak. It comes with trade-offs worth naming:
The cost of a wildcard
One private key now authenticates every subdomain it covers, so if that key leaks, an attacker can impersonate all of them until it is rotated - a bigger blast radius concentrated in one key and one renewal process. A wildcard also matches only a single label level: *.example.com covers a.example.com but not b.a.example.com. And the apex domain is still right there in the certificate. So a wildcard hides the list of subdomains from CT specifically; it does not make your infrastructure invisible.
//What Still Leaks, and the Real Answer for Internal Services
Even with a wildcard, the hostname can leak through other channels: public DNS records, the TLS SNI sent in cleartext before Encrypted Client Hello, and passive-DNS datasets. CT is one discovery channel among several; closing it is not the same as being undiscoverable.
For a service that is genuinely internal, the clean answer is to not use a publicly-trusted certificate at all. A private or internal CA is not subject to CT - its certificates are never submitted to public logs, so crt.sh will never show them. That removes the CT channel entirely. It does not remove the others: if the host still resolves in public DNS or you reach it over a network an observer can watch, those can leak the name regardless. The discipline is the same as everywhere else on this site - name the discovery channel you are actually closing, and do not mistake it for all of them.
//Sourcing and Framing
The CT mechanism (append-only Merkle-tree logs, signed timestamps) is from RFC 6962; the point that CT is effectively mandatory via browser policy rather than the RFC - Chrome since 30 April 2018, Apple's platforms likewise - is from the Chromium CT documentation and Apple's trust policy, and RFC 6962 has since been obsoleted by RFC 9162 though the deployed ecosystem still runs on v1. Subdomain enumeration via CT logs as a standard recon technique, with the crt.sh query, is from the OWASP Web Security Testing Guide. The wildcard behaviour and its shared-key trade-off, and the single-label-level limit, are from CT and PKI references; the private-CA point follows from CT applying only to publicly-trusted certificates. The residual DNS/SNI leakage is the same mechanism covered in the encrypted-DNS piece. The interpretation is that CT is a good system whose transparency is total by design, so "secret subdomain" is not a thing you can have.