Compromised eMudhra intermediate CA prompts a guide to CT log monitoring and CAA records

What happened

A post on dev.to, pointing to a Hacker News thread that had drawn more than 600 points, describes the compromise of an intermediate certificate authority operated by eMudhra. According to the author, most developers in the thread shrugged it off as a problem for browser vendors. The post argues the opposite: when an intermediate CA leaks its key or misissues, an attacker can hold a fully valid certificate for your domain. The browser shows its usual padlock, users notice nothing unusual, and you stay unaware until something actually breaks.

The article walks through three countermeasures the author says cost nothing and can be set up the same day: watching Certificate Transparency logs, restricting certificate issuance with CAA DNS records, and auditing the certificate chains your production servers actually present.

Why a compromised CA is your problem

As the post explains, the TLS trust model is wide open by design. Browsers trust on the order of a hundred root CAs, each delegating to multiple intermediates, and any CA in that chain can sign a certificate for any domain unless the domain owner explicitly says otherwise. There is no built-in rule that reserves your domain to one particular issuer.

The partial remedy is Certificate Transparency. Since 2018, per the article, Chrome has required every publicly trusted certificate to carry a Signed Certificate Timestamp, which means it must be recorded in a public CT log; Safari enforces a comparable policy. So a fraudulent certificate that browsers will accept is almost certainly sitting in a public log. You just have to go look at it.

Monitor Certificate Transparency logs

The recommended tool is crt.sh, a free CT log aggregator run by Sectigo that exposes a JSON endpoint. The author shares a Python script run hourly from cron: it fetches all certificates for the configured domains, keeps a whitelist of allowed issuers such as Let's Encrypt and Google Trust Services, and raises an alarm whenever a new certificate appears from an issuer outside the list. The script returns a non-zero exit code on alerts so cron or CI can forward output to a Slack or Telegram webhook.

The author's practical notes: crt.sh frequently times out for domains with many certificates, so use long timeouts and retries; the first run flags your entire certificate history, so seed the state file once before enabling alerting; and teams wanting real-time coverage can subscribe to CT streams through the certstream library, though hourly polling is generally enough because rogue certificates tend to be exploited over days, not minutes.

Lock issuance down with CAA records

Monitoring detects problems; CAA (Certification Authority Authorization, RFC 8659) aims to prevent them. According to the post, the CA/Browser Forum has required every CA to check a domain's CAA records before issuing since 2017, so a DNS entry can declare that only, say, Let's Encrypt and Google Trust Services may issue for your zone, that wildcard issuance is forbidden outright, and that violations should be reported to an iodef contact address. A single dig +short CAA example.com shows whether a zone is currently unrestricted, which means every CA on earth is allowed to issue for it.

The author is blunt about the limits: CAA cannot save you when a CA is fully compromised, because an attacker holding the signing key is not going to consult DNS. Its real value is against the far more common failure modes — flawed domain validation, social engineering against a CA, and issuance by an unusually permissive authority.

Audit the chains you actually serve

When news breaks that a CA has been revoked or distrusted, the first question is whether your own servers are serving certificates from that chain. Rather than guessing, the post provides an OpenSSL script that connects to each host, splits the presented chain into leaf and intermediate certificates, and prints the subject, issuer, expiry and SHA-256 fingerprint of each. Those fingerprints can be matched against the distrusted-intermediate lists that browser vendors publish.

The author closes with an often-missed point: a fraudulent certificate for your domain does not necessarily come from a hacked CA. Frequently the DNS zone or registrar account was compromised and the attacker simply passed DNS-01 validation to obtain a perfectly legitimate certificate. The final recommendations are therefore two-factor authentication at the registrar, registry locks for critical domains, and a standing checklist covering CAA queries across all production domains, hourly CT monitoring, and the chain-check script kept in the incident runbook.

Why it matters

As the post notes, eMudhra is not the first and will not be the last: DigiNotar, Symantec and TrustCor all went before it. Developers cannot control how CAs behave, but they do control how early they learn about abuse. CAA provides a prevention layer against misissuance, and CT logs provide a detection layer that works even when prevention fails — one of the few attack categories where the attacker's artifacts are published in public logs before the damage is done.