Certificate Transparency logs make certificate issuance observable. RFC 9162 describes a protocol in which logs record certificates, return signed tree heads, and provide inclusion and consistency proofs. For a domain owner, the practical value is simpler: unexpected public certificates can be found by comparing issued names with an inventory of intentional services.
The logs do not authorize a certificate and cannot make an insecure service secure. A logged certificate may be valid, malicious, duplicate, or an authorized test. The work is to define who can distinguish those cases and how quickly.
Design the monitor around names
Start with the domains, subdomains, and wildcard patterns the organization owns. Include names used by APIs, email infrastructure, customer tenants, and temporary environments. Match certificate names against that list and route exact matches, wildcard expansions, and unknown names differently. A wildcard certificate for a broad corporate domain should raise a more urgent review than a test name that maps to a documented sandbox.
The monitor should preserve the certificate's issuer, serial number, subject alternative names, not-before and not-after dates, public-key identity, and the log entry or signed certificate timestamp. These fields let the owner verify whether the certificate is the same object that was approved. The hash of a certificate alone may not be enough when a CA has reissued a certificate with the same name and key.
Use more than one source when possible. A public log is an observation point, not the organization's entire PKI inventory. Internal CAs, private keys protected by a hardware module, and services not exposed on the public web may need a separate inventory. If the organization uses certificate deployment automation, connect the approval record to the issued certificate and to the DNS or service that consumes it.
Give someone authority to act
The response path needs an owner. A team that can only send alerts will be slow when an unexpected certificate is found. Define who can revoke the certificate, remove a public key, rotate a secret, contact the CA, and investigate DNS or validation records. Test the path with a harmless known certificate before an incident.
Do not automatically revoke every certificate that is absent from an allowlist. A new service or a legitimate vendor may be missing from inventory. First determine whether the name belongs to the organization, which account requested it, and what private key it corresponds to. Containment can be temporary while the investigation proceeds.
Monitor log and monitor health as well as certificate events. A feed that stopped receiving entries, a missing consistency proof, or a watcher that silently lost credentials produces an appearance of safety. Track feed age, ingest errors, and unresolved detections. Keep the last known-good state so an operator can tell an empty log from a broken collector.
Certificate Transparency is most useful when it is one input to a known inventory and response process. The logs expose issuance; ownership, key custody, and certificate lifecycle remain local responsibilities.