eMudhra’s script cut 8 keys to a byte; its TLS issuing stops 16 November

01One line in a key-moving script

At a ceremony on 30 April 2025 eMudhra generated 16 issuing-CA keys, eight ECDSA P-384 (G3B and G3C) and eight RSA-4096 (G2B and G2C), on a Utimaco module. They were meant for its new US and EU facilities, but the Crypto4A modules ordered for the US were delayed, and a root-program rule taking effect on 15 June 2025 meant the keys had to exist before the end of May. So the team generated them on hand and planned to move them by key wrapping, with FIPS-approved mode switched off for the step.¹

After the round trip, the script read each unwrapped private key into the host computer’s memory and re-created a key object from it. For the ECDSA keys that read-back truncated the value, leaving a private key below 256; the re-created object, carrying an almost identical label, was the one used to request the certificate. The RSA keys came through intact, but because their material passed through a Python process on the ceremony host, eMudhra says it “cannot positively demonstrate” they met its own rule on moving keys, and revoked those eight as well.¹

02The warning sign in June 2025

Between 29 May and 6 June 2025 the revocation lists of six G3 TLS intermediates failed to verify, because the certificates had been issued over the re-created keys while the lists were signed with the originals. eMudhra re-signed them with the matching key; its report says the fix “did not reach the underlying cause” and calls the episode an early indication of the defect. The ceremony never tested key strength or compared the certified key with the generated one, which the industry’s Baseline Requirements do not require, and two WebTrust audit cycles passed.¹

The Chrome Root Program has said why its own checks missed the keys for 18 months: standard linting tools did not test for small elliptic-curve private keys, and Google’s scanner covered only certificates logged to Certificate Transparency, which these dormant intermediates never were. It now scans CA certificates disclosed to the CCADB and has proposed a weak-key check before any can be disclosed.⁴ eMudhra appointed KPMG to review the incident; improvements from that review are due by 4 December, and an inventory of all its CA keys by 30 November.³¹

03What an Indian site on an eMudhra certificate must do, and by when

Chrome and Firefox will not trust a G1 certificate issued after 16 November, though earlier ones keep working until they expire. Apple removes G1 on 30 November, after which no G1 certificate, whenever issued, is trusted on its platforms. eMudhra says it has moved every emSign TLS customer outside the US to other providers at no charge, and that its digital signature certificates and eSign run on separate infrastructure and are unaffected.³ Its remaining TLS customer is a university federation in North America, moving to another publicly trusted provider.¹