Let's Encrypt for Internal Domains: What CT Logs Make Public

Let's Encrypt for internal domains works: the DNS-01 challenge proves you control a domain without any server answering from the internet, and wildcard certificates come the same way. What it does not do is keep the name private. Every certificate a browser trusts is written to public Certificate Transparency (CT) logs. A service on a private address behind a VPN therefore still has a public hostname, and its issue dates and renewals are on record for anyone to read.

A public certificate means a public name. Choose a certificate per host, a wildcard or a private CA by how much of the name you can afford to publish, and protect every service as if its name is already known.

What a certificate publishes the moment it is issued

Before issuing, a CA submits a precertificate to the logs. It is the certificate-to-be plus a critical extension, called the poison, that makes standard clients refuse it. The logs answer with signed timestamps (SCTs), and the CA embeds them in the real certificate. Nearly every CA works this way, so the hostname is public before the certificate exists. Chrome and Apple platforms both require signed proof from logs run by at least two separate organizations, so a publicly trusted CA cannot skip the step and a site owner cannot opt out.

The log entry holds the whole certificate. For a domain-validated certificate, the kind Let's Encrypt issues, that means the names it covers, the issuer and the validity dates. Neither the server's address nor what it runs is in the entry. The leak is the name, which usually tells you what the host is for. Internet-wide scans already aggregated certificates, but the logs make the collection complete and early, and let anyone search it by name without connecting to your server. The entries for a domain, read as a list, give a stranger:

• the services you run, from labels such as vault, grafana, jenkins or vpn;
• products and customer names before any announcement;
• the date each host appeared and whether its certificate keeps renewing;
• a ready target list, if the same names also resolve in public DNS.

Newer logs publish their contents as plain files that any client can download, and some add a compact list of just the names. For logs that Chrome accepts, the time a log may take to include an entry is capped at one minute for these static logs and four hours for the older kind. Soon after a Let's Encrypt certificate is logged, automated crawlers can find the new hostname and request it, and a public web server sees that traffic in its access log. Logs are append-only, so a name stays listed after its certificate expires or is revoked. The full Certificate Transparency background covers logs, SCTs and browser enforcement in more detail.

Let's Encrypt for internal domains: what DNS-01 solves and what it publishes

Let's Encrypt checks control of a name with a challenge. HTTP-01 needs a web server answering on port 80. DNS-01 needs only a TXT record in the domain's public DNS, so it works for hosts that are not exposed to the internet, and only DNS-01 can issue a wildcard. The renewing machine then holds a DNS API credential, and one that can edit your whole zone is a risk on a web server, so scope it narrowly or run the validation elsewhere.

The name must sit under a domain you own in public DNS: public CAs may not issue for names that do not end in a registered top-level domain, so names ending in lan or local are out.

On the publishing side, Let's Encrypt submits every certificate it issues to CT logs. Its default lifetime is 90 days, with renewal advised every 60, and six-day certificates are opt-in. Industry rules cap lifetimes at 200 days now, 100 from March 2027 and 47 from March 2029, so a per-host certificate puts the same name into the logs more often each year.

Wildcard certificate subdomains: what stays hidden

A wildcard certificate for *.lab.example.com covers exactly one label below lab.example.com. It matches vault.lab.example.com and rejects a.vault.lab.example.com or api.example.com. The log shows the wildcard and the zone label, lab, and none of the hosts under it, so the individual service names never appear.

What a wildcard does not hide:

• Guessable names. A dictionary of common labels such as mail, dev, vpn and staging, each checked in DNS, finds hosts whatever certificate they use.
• Any host that also gets its own certificate, even once, from another CA or a test run.
• Names published in public DNS. Internal-only DNS answers, often called split-horizon, close that route.

Are wildcard certificates less secure?

A wildcard is less secure in one respect: what a stolen key is worth. Its private key sits on every machine that serves a name under it, so the weakest host exposes all of them. Whoever holds the key can impersonate any name in the zone to anyone whose traffic they can redirect. Give each environment its own zone and its own wildcard, and keep the key off machines that do not serve it. The domain owner can also narrow who may issue at all: CAA records list the authorized CAs and can carry a separate rule for wildcard names.

Private certificate authority for internal names

A certificate from your own CA never reaches the public logs. The logs do not accept certificates from CAs that browsers do not trust by default, and CT applies only to publicly trusted CAs, so a certificate signed under a root you installed yourself is outside it. For names only your organization uses, a private CA is the usual answer. The price is operational. You run the CA or rent a hosted one, guard its key, and install its root on every device that must trust it. That rules out visitors' phones and anything you do not manage.

Certificate transparency monitoring: what to do about it

Logs also work in your favor, because a certificate you did not request shows up in them as well. A monitor reads the logs for your domain and sends an alert for each new certificate. Cloudflare's CT Monitoring, generally available on every plan since August 2026, is opt-in and emails you about certificates for your domain from any other issuer. It only watches your own names, so a certificate for a lookalike domain raises no alert.

1. Look up your domain as an outsider would. The Subdomain Finder from packet.guru combines Certificate Transparency data from crt.sh with roughly a thousand common names, checks each in DNS and lists the names that exist now, showing the address, country and network of each. A name that only survives in an old certificate and no longer resolves is dropped, so search crt.sh as well for the full history.
2. Sort every name as reachable from outside or internal. An internal name with its own public certificate is a candidate for a wildcard on a separate zone, or for a private CA. The two combine: a public wildcard for services outside visitors must reach, a private CA for the rest.
3. Treat every label as public. Keep customer names, unreleased products and role hints such as prod or admin out of hostnames that will ever get a public certificate.
4. Put real access control on the service itself. Login, a VPN or an allowlist has to carry the protection, because the name will not.
5. Check what each server presents: the certificate it serves lists its Subject Alternative Names, issuer and validity window, and any SSL checker shows them. Then turn on monitoring and publish CAA records.