What happened
Mozilla received a report on Saturday, October 17, from a community member: private keys tied to eight intermediate certificates issued by eMudhra, an Indian certification authority, had been compromised. Those keys would let an attacker mint valid HTTPS certificates for domains they do not control. Cloudflare's summary was blunt. An attacker can forge a certificate for any domain and use it to impersonate a server, intercepting or modifying traffic.
The response moved quickly. eMudhra revoked the certificates, and Mozilla, Chrome and Apple shipped updates so their browsers stop trusting them once installed. A number of open source projects issued updates with the same effect. Dennis Jackson of Mozilla's cryptography engineering team published the timeline and the detail.
Then came the part that turned an incident into a reputation problem. Security researcher Scott Helme recovered the private keys from eMudhra's public certificates on a laptop, in under a second, and found that one of them was the number 4. Not a number beginning with 4. The number 4. Others were 56 and 115, and further researchers found 66, 155, 156, 230 and 237. A P-384 private key is supposed to be a random 384 bit value with roughly 2 to the power 384 possible values. Keys this small can be searched by brute force.
eMudhra, which states it has issued more than 60 million digital certificates, had not responded to The Register's questions about the incident or its security practices at the time of publication.
Why this is a GRC story
This is a key management failure, not a cryptography failure. The algorithm worked exactly as specified. The problem was the generation of key material, which is a process, and processes have owners, procedures and tests. A control that says "keys are generated to standard" is a claim. A control that says "key generation is tested and the output is checked for entropy" is evidence. Only one of those survives an audit.
Third party trust is now a scoped, evidential question. Any organisation that terminates TLS with certificates from a smaller or regional authority has to ask a new question this week: which of our services depends on a certificate chain from an issuer that a browser no longer trusts. Browsers will reject bad certificates automatically. Internal applications, appliances, code signing pipelines and machine to machine clients often will not, and they are where the clean up will be slow.
Revocation is not the same as remediation. The certificates are revoked and the roots are distrusted, yet signed certificates using those keys remain in the wild. The gap between the two is where outages happen, and it is measured in how fast an inventory can be produced.
What to watch
Watch the root programme response. Browser root stores have removal processes, and the question of whether eMudhra keeps its trusted status after keys this weak is the one that matters commercially for every customer holding its certificates.
The operational lesson is smaller and more useful. Certificate inventory and automated renewal are not housekeeping. If a CA can be distrusted on a Saturday night, the ability to answer "where do we use these" by Sunday morning is a resilience control, and it belongs in the same conversation as backups and failover.
Attribution: Analysis based on The Register and related public reporting. This article is original commentary, not a repost of the source material.