By Yair Knijn · March 17, 2025

The shadow certificate no platform team knows about, until it shows up in a CT log search

Most platform teams treat the provisioning pipeline as the registry of truth. If a certificate exists, the pipeline issued it, logged it, and tagged it to an owner. That belief holds right up until someone runs a crt.sh query against the corporate apex and gets back forty hostnames nobody on the call recognizes.

None of them came from the pipeline. A team needed TLS on a vendor integration, ran certbot against a domain they already controlled, and shipped before lunch. The cert is real, publicly trusted, and reachable. It is also invisible to the one inventory the security team trusts, and perfectly visible to everyone else on the internet.

How CT logging works and why every public cert is visible in seconds

Certificate Transparency, specified in RFC 6962, requires every publicly trusted certificate to be submitted to append-only, cryptographically verifiable logs. The CA submits a precertificate, the log returns a Signed Certificate Timestamp, and that timestamp is embedded in the final cert. Chrome has refused to trust certificates without valid timestamps since 2018, and Apple enforces its own log policy. A cert that never reaches a log simply will not load in a browser.

So the moment you issue a certificate, its full subjectAltName set becomes queryable on public infrastructure like crt.sh, which Sectigo runs over the logs. Nobody opts in. Logging is the price of being trusted, and the log is global, permanent, and free for anyone to read.

Shadow certs: services provisioned outside the standard pipeline

A shadow cert is any publicly trusted certificate for your namespace that your inventory cannot account for. Most of them are harmless byproducts of teams under deadline: a Let's Encrypt cert on a staging box, a SaaS vendor auto-provisioning customer.yourbrand.com after you pointed a CNAME at them, a contractor who stood up a demo and walked away. The dangerous minority are mis-issuance and lookalike domains, the exact failure mode CT was built to surface.

Either way, the subjectAltName tells a story you did not mean to tell. Internal naming leaks straight into the open: jira-internal, vpn-test, and admin-staging announce your architecture to anyone parsing the logs. An outsider building a target map gets a cleaner enumeration of your estate from CT than your own CMDB holds, because the logs never miss an issuance and your CMDB depends on a human remembering to file one.

Turning CT monitoring into a continuous shadow-IT detector

CT search is pull, not push. Nobody pages you when a new cert appears. You have to ask, and by the time a quarterly review thinks to ask, a phishing host or an unmanaged service has been live for weeks. Flip the model: treat the log stream as ground truth, and audit the pipeline against it.

• Define the authorized set: the SANs and issuing CAs your pipeline actually produces, keyed per business unit or tenant.
• Ingest CT continuously for every domain you own, not just the apex, including wildcard and second-level zones.
• Diff every new entry against that set and raise anything unmatched as a security event, not a backlog ticket.
• Set CAA records so only sanctioned CAs can issue, shrinking the unexpected-issuance space before monitoring even runs.

From crt.sh spot-checks to alerting on unexpected hostnames

A crt.sh query during an incident is forensics. By then the cert is months old and you are reconstructing who issued it and why. What changes the outcome is moving from spot-check to standing alert: subscribe to the log stream, and the question becomes "did we authorize this hostname," answered at issuance time, while the owning team still remembers the change and revocation is cheap.

This lines up with where the ecosystem is going. The CA/Browser Forum has voted to cut maximum certificate lifetimes toward 47 days by 2029, which means far more issuance events per host every year. More issuances means more chances for a shadow cert to slip in unnoticed, and a lot more noise to triage if your only tool is a manual search.

Automate Certificates closes that gap by making the issued reality and the intended reality the same record. Every certificate carries its owner, its SANs, and its issuing CA, so CT entries that do not match surface as alerts instead of audit-day surprises. When an outsider can inventory you from public logs, the only acceptable answer is to inventory yourself first. See how the monitoring and inventory features turn the CT stream into your own early-warning feed.