Every publicly trusted certificate is submitted to append-only public logs, and browsers refuse certificates that are not. That obligation, designed to catch misissuance, is also a real-time feed of who is preparing to serve what.
What an entry contains
| Field | Discloses |
|---|---|
| Subject Alternative Names | Every hostname the certificate covers. The valuable field. |
| Issuer | Which CA issued it. |
| Not before / not after | The validity window — and therefore roughly when it was obtained. |
| Serial and fingerprint | Identity of the certificate itself, for linking. |
| Log entry timestamp | When it was submitted, usually within minutes of issuance. |
$ curl -s 'https://crt.sh/?q=certadns.com&output=json' | jq -r '.[].name_value'
bimi.certadns.com certadns.com www.certadns.com certadns.com www.certadns.com
It discloses names you never published
bimi.certadns.com appears in no navigation, no sitemap and no public page. It is in the log because it was in a certificate, and it will be there permanently.
- Every internal hostname you put in a certificate is public. Staging, admin, VPN, a customer name.
- Wildcards are the mitigation. A certificate for
*.example.comdiscloses one name rather than fifty, at the cost of a key that covers everything. - It cannot be undone. The logs are append-only by design, so a name disclosed once is disclosed permanently.
Finding an attacker’s set
Search the logs for your brand string: crt.sh ?q=%25northwind%25 Returns every certificate whose SANs contain it — including lookalikes, subdomains of attacker domains, and combosquats you never generated. Then pivot: a certificate covering several names links them all to one operator.
A certificate is not evidence of wrongdoing
Anyone may obtain a certificate for a domain they control, including a domain resembling yours. The log entry establishes that the name exists, is controlled by someone, and is about to serve HTTPS. What it is serving is a separate question you have to go and look at.