| name | audi-tls-cert-trns-logs |
| description | Monitors Certificate Transparency (CT) logs to detect unauthorized certificate issuance, discover subdomains via CT data, and alert on suspicious certificate activity for owned domains. Uses the crt.sh API and direct CT log querying based on RFC 6962 to build continuous monitoring pipelines that catch rogue certificates, track CA behavior, and map the external attack surface. Activates for requests involving certificate transparency monitoring, CT log auditing, subdomain discovery via certificates, or certificate issuance alerting.
|
| domain | cybersecurity |
| subdomain | threat-intelligence |
| tags | ["certificate-transparency","CT-logs","crt-sh","subdomain-discovery","TLS-monitoring","RFC-6962"] |
| version | 1.0.0 |
| author | mukul975 |
| license | Apache-2.0 |
| nist_csf | ["ID.RA-01","ID.RA-05","DE.CM-01","DE.AE-02"] |
Auditing TLS Certificate Transparency Logs
When to Use
- Monitoring owned domains for unauthorized or unexpected certificate issuance by unknown Certificate Authorities
- Discovering subdomains and hidden services through certificates logged in public CT logs
- Detecting phishing infrastructure that uses look-alike domain certificates (typosquatting, homograph attacks)
- Auditing Certificate Authority compliance by verifying all issued certificates appear in CT logs as required by browser policies
- Building continuous certificate monitoring into a security operations pipeline with alerting for new issuances
Do not use for attacking or disrupting Certificate Authorities, for scraping CT logs in violation of rate limits or terms of service, or as the sole method of subdomain enumeration without corroborating results through DNS verification.
Prerequisites
- Python 3.10+ with
requests, cryptography, and pyOpenSSL libraries installed
- Network access to crt.sh (HTTPS) and public CT log servers
- A list of domains to monitor (owned domains, brand variations, typosquat candidates)
- SMTP credentials or webhook URL for alerting on new certificate discoveries
- Basic understanding of X.509 certificate structure and TLS certificate chain validation
Workflow
Step 1: Domain Inventory and Baseline
Build the initial certificate inventory for monitored domains:
- Define monitoring scope: List all owned root domains, registered brand names, and known subsidiaries. Include wildcard patterns (
%.example.com) for comprehensive subdomain coverage.
- Query crt.sh for historical certificates: Use the crt.sh JSON API to retrieve all known certificates for each domain. The API endpoint
https://crt.sh/?q=%.example.com&output=json returns certificates matching the wildcard pattern with fields including issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after, and serial_number.
- Build baseline database: Store the initial certificate set in a local SQLite database with columns for certificate ID, domain, issuer, validity dates, SANs (Subject Alternative Names), and first-seen timestamp. This baseline prevents alerting on already-known certificates.
- Identify authorized CAs: From the baseline, extract the set of Certificate Authorities that have legitimately issued certificates for your domains. Any future issuance from a CA not in this set triggers a high-priority alert.
