Is your infrastructure trusting a compromised CA?

When a public certificate authority discloses that one of its intermediate CAs has been compromised, the blast radius is not the CA's own website — it is every system that was built to trust certificates signed beneath that intermediate. The EMudhra disclosure drew hundreds of comments on Hacker News within a day, and the recurring question in that thread was not philosophical: engineers wanted to know, concretely, whether their own domains were affected. That question is harder to answer than it looks, because the certificate your browser shows is only the leaf. The trust decision happens further up the chain, in an intermediate that most teams never inspect and rarely inventory.

Existing tools do not answer this question cleanly. General SSL checkers grade your configuration, report cipher suites, and hand you a letter grade — useful for hardening, useless when you need to prove to an incident commander that a specific CA is or is not in your trust path. Certificate transparency logs tell you what was issued for a domain historically, but not what your server is actually presenting today. Enterprise certificate managers solve the problem at scale, but they assume a procurement cycle you do not have during a live incident. What is missing is a narrow, one-shot artifact: a report that says, per domain, whether the compromised chain appears, with fingerprints and timestamps you can attach to a ticket.

That gap is why this tool exists now rather than as a general product. Incident windows are short. The useful output is not a dashboard you check daily — it is a document you generate once, paste into Jira or PagerDuty, and move on. The signal here is a security event, not a recurring workflow complaint, so the right shape is a fast self-audit that produces a deliverable, not another monitoring subscription.