eMudhra’s CA key was 4. What still trusts it?
An intermediate CA private key with the value 4 sounds like a test somebody forgot to remove. The eMudhra incident is real. The question for an infrastructure team is what still trusts those keys, and how to prove your running applications reject them.
Checking the expiry dates on your own certificates will not answer that. Neither will opening the website in an updated browser.
What has actually been confirmed
Mozilla’s incident report identifies eight compromised intermediate CA keys: six for TLS and two for code signing. Mozilla received the report on 17 October and independently recovered the keys. All eight private values were below 256.
Scott Helme reproduced the recovery, including the value 4 for EM OV TLS CA - G3C. A P-384 private key should be selected securely across an enormous range. These keys could be found by trying a tiny set of candidates against the public certificates. The public keys were structurally valid; that did not make their private values unpredictable.
In its preliminary account on the incident ticket, eMudhra describes a ceremony-script flaw that produced a second, weak set of keys, then a label mix-up that led to those keys being used for certificate requests. Treat that as the CA’s explanation under investigation, rather than a completed independent root-cause analysis.
The widely repeated “60 million certificates” figure is a cumulative issuance claim. It does not establish that every certificate eMudhra ever issued used one of these keys. Scope the response using the affected certificates, keys and trust paths in the incident disclosures.
Browser protection is only part of the response
Chrome’s response explains that it blocked the affected TLS public keys through CRLSet on 17 October, covering the cross-signed copies too. Mozilla blocked the certificates in Firefox through OneCRL that evening. Neither mechanism required a browser restart.
Chrome also says no TLS certificates chaining to those intermediates had been logged to Certificate Transparency before its block. Its default CT enforcement therefore prevented such fraudulent certificates from being trusted. The ability to forge a certificate is serious; it is not evidence that every browser was silently intercepted.
The awkward remainder is software with a different verification path. Cloudflare’s response describes work across trust stores, base images, applications and running services. It makes a useful point: a browser check, or a curl check, only tests that particular verifier.
Your background service may use something else.
There are two separate jobs
| Where you are looking | What needs attention | What would demonstrate progress |
|---|---|---|
| Clients making outbound TLS connections | The verifier and trust configuration used by the running application | The actual application rejects the affected trust path while legitimate connections still work |
| Services presenting an affected or newly distrusted chain | Replacement issuance, delivery and service activation | The listener serves an acceptable replacement chain and the clients that matter accept it |
The first job applies even if you have never bought an eMudhra certificate. A client that trusts an affected chain could accept an attacker’s certificate for an unrelated service it calls.
Replacing the certificate on your own website does not change what your payment integration, build runner or outbound proxy trusts. Equally, updating a client’s trust store does not replace a certificate on your HAProxy or IIS listener.
This distinction should be visible in the incident ticket. Otherwise, “certificates updated” can conceal an unfinished job.
What I would want from the infrastructure review
Start with one real service and follow both directions: the certificate it presents and the remote systems it authenticates.
- Name the owner and the running workload. Record the service, environment and person responsible. Include scheduled jobs and supplier integrations, not just the public website.
- Identify how it makes trust decisions. Establish whether it uses the operating system, a runtime bundle, a Java truststore, a mounted file or custom application configuration. Record the deployed version rather than the version on a developer’s laptop.
- Apply the relevant vendor remediation and activate it. Follow the current incident guidance for that stack. Establish whether a rebuild, restart or redeployment is needed. A patched base image is not evidence that a container already running has changed.
- Handle served certificates separately. Compare the chain with the incident’s affected material and the root policies of your clients. If replacement is needed, confirm the proposed issuer and chain will be accepted before rolling it out. Repeating the old renewal job may return another unusable chain.
- Keep evidence from the real path. Record the workload version, verification result, served chain and any remaining exception. Give systems that cannot be updated an owner and a response plan.
Cloudflare explicitly advises testing through the application’s actual TLS path and keeping verification enabled when certificate errors appear. Use the current Mozilla disclosure and your software vendors’ advisories for the affected material and remediation. This article is an operational response framework, checked on 21 October 2026.
The audit question needs a technical answer
The failure deserves scrutiny. I would want to know which checks should have rejected the weak keys, what evidence the ceremony produced, and why the wrong key objects reached signing.
“Compliance only checks paperwork” is too broad to explain that. The useful lesson for an operator is to connect a documented control to evidence of the result: what was generated, selected, signed, deployed and verified. An expiry dashboard cannot supply all of that.
Where CertLocker helps
For the certificates your team manages, CertLocker keeps inventory, issuer details, ownership, ACME workflows, scoped delivery and audit events together. Its certificate Automations handle the configured installation and activation steps; endpoint probes inspect what a reachable listener actually presents.
That supports the service-replacement part of this response: find the managed certificate, identify its owner and targets, obtain an acceptable replacement, deliver it and check the live result. The certificate delivery build note shows how we compare the selected certificate with the fingerprint served after deployment.
Outbound client remediation still needs its own software inventory, vendor updates and application testing. CertLocker does not validate a public CA’s key ceremony or automatically patch every application trust store. A probe result is an observation from one place at one time; it does not establish that every client rejects a forged chain.
The question to take back to your team is practical: if an issuer becomes untrusted today, can you name the affected services, change what they serve or trust, and show the result?
If you want to work through the certificate side together, arrange a face-to-face meeting or video call. We can demonstrate the hosted CertLocker inventory, delivery and probe workflow against the way your team works today.