Certificate Transparency (CT)

You give your NAS a real certificate under nas.home.example.com and tell nobody. The name is public anyway – the certificate was published, on purpose.

The short answer

Certificate Transparency (CT) is a system of public, append-only logs in which TLS certificates are recorded, so that anyone can audit what certificate authorities issue [1][2]. Browsers such as Chrome and Safari only accept publicly trusted certificates that carry proof of logging [1][4]. Why do your subdomains show up? Every certificate lists the names it is valid for, and anyone can query the logs, so each hostname in a public certificate becomes visible, internal ones included [1]. Our assessment: CT helps you as a domain owner, as long as you keep names that should stay private out of public certificates.

How it works

1. Append-only logs. A CT log is an append-only ledger of certificates. It is built as a Merkle tree, so anyone can query a log and verify that it behaves correctly [1][2].
2. The receipt. When a certificate authority submits a precertificate, the log returns a Signed Certificate Timestamp (SCT), a promise to add the certificate within the Maximum Merge Delay, usually 24 hours [1]. Most often the SCT is embedded in the certificate; OCSP stapling and a TLS extension are less common ways to deliver it [1].
3. Browsers check. Safari and Chrome require at least two SCTs, depending on the certificate's lifetime [1]. Chrome requires CT for all publicly trusted TLS certificates issued after 30 Apr 2018 [4].
4. Who logs. Let's Encrypt submits every certificate it issues to CT logs and runs its own logs, Sycamore and Willow, built on Sunlight; its older logs based on RFC 6962 are end-of-life [3].
5. The standards. RFC 9162 from December 2021 defines CT version 2.0 as an Experimental protocol and obsoletes RFC 6962 [2]. Chrome's policy still refers to RFC 6962, expanded by the static-ct-api [4].
6. Monitoring. Monitors are publicly run servers that regularly fetch all logs and watch for suspicious certificates; domain owners can subscribe to them or run their own [1]. RFC 9162 describes exactly this use: checking whether domains you are responsible for got certificates you did not expect [2].
7. The side effect. Our reading: because the logs are public, a certificate for nas.home.example.com tells everyone that this name exists. A wildcard certificate for *.home.example.com only shows the wildcard, not the names of the individual services.

A practical example

Your homelab, the servers you run at home, uses names like nas.home.example.com behind a reverse proxy. Instead of one certificate per service, you request a single wildcard certificate for *.home.example.com; with Let's Encrypt that requires the DNS-01 challenge, which our entry on it explains. The logs then show *.home.example.com, but not which services exist behind it. Next, search a CT search site such as crt.sh once for your domain to see what is already public, and subscribe to a monitor that reports new certificates [1]. The names are made-up examples, not our hosts.

Checklist

• Search the CT logs for your domain once to see which hostnames are already public.
• Subscribe to a CT monitor or run your own to learn about new certificates for your domain [1].
• Use a wildcard certificate for internal services whose names should stay private.
• Keep revealing words such as admin or backup out of hostnames in public certificates.
• Investigate any certificate for your domain that you did not request [2].
• Protect the services themselves, because a hidden name is no access control.