Uptime and expiry checks cannot see a certificate that was never served on your server

Both halves of the standard TLS monitoring bundle share a vantage point. They open a connection to a host you already run and report on what that host hands back: a status code from the origin, and the `notAfter` field on the certificate your own server presents ^[1]. A certificate issued for a name under your domain and served from infrastructure you do not control never enters the field of view of either probe ^[1][2]. Neither is a tuning failure. The sensor is in the wrong place.

Certificate Transparency moves the sensor to the issuance side. Per the dev.to write-up, CT is specified in RFC 6962 as an append-only, cryptographically verifiable public record, and a CA submits each certificate it issues to independent logs, receiving a signed certificate timestamp in return ^[3][4]. The part that makes this dependable rather than aspirational is the browser enforcement: since 2018, Chrome, Safari and others refuse to trust a publicly trusted certificate that does not carry valid SCTs, so a certificate the CA declined to log is a certificate that fails in a browser ^[5]. For the case that actually costs you something, a phishing page with a working padlock, the attacker cannot opt out of the log without breaking their own tool. The set of certificates for your name that work against a victim is a subset of the set you can enumerate for free ^[15].

Read the issuance routes the post lists and count how many require a CA to be compromised. None do ^[14]. Domain validation proves control, not ownership, so answering an HTTP-01 challenge on your host or writing a TXT record in your zone is sufficient ^[6]. That covers a brief DNS compromise, a `CNAME` still pointing at a de-provisioned cloud resource, and a stale record left behind by a migration ^[7]. It also covers the contractor, the old CI pipeline and the marketing SaaS you connected a subdomain to years ago, any of which can still mint a certificate today unless that control was explicitly revoked ^[8]. Lookalike and adjacent names sit outside that model entirely, but they are keyed on the string in the log, so a query that watches the registrable name and its neighbours catches them ^[9].

The reading is cheap. `crt.sh` answers wildcard subdomain queries as JSON with no account, and certspotter's issuance API returns one row per certificate on an authenticated free tier ^[10][11]. The honest limit is stated in the source and worth restating: one query describes today, and says nothing about the certificate issued three weeks from now ^[13]. A single run is an audit. A monitor is a stored baseline plus a scheduled diff, and the difference is entirely in whether anyone keeps the previous output.

The triage that follows converts a detection problem into an inventory problem. Each row asks whether you recognise the issuer, the hostname set and the issuance date ^[12], which you can only answer if you know what your own teams legitimately ordered. That is where most of this work lands, and the source stops at detection: it tells you how to find the row, not what you are supposed to do about it once the certificate exists and browsers already trust it.