Weak keys at certificate issuer eMudhra force Go and Java into emergency patches
The Go team looks back on its first ever emergency release; Java applications remain exposed as long as their list of trusted certificates has not been updated.
In April 2025, the Indian certificate authority eMudhra created eight intermediate certificates with keys that were extremely weak because of insufficient randomness. According to Help Net Security, every private key was below 256, so an attacker needed at most 256 attempts. Researchers extracted the keys from the public certificates in under a second, CSO Online reports. Six certificates were used for TLS and two for signing software. Anyone holding the keys could issue trusted certificates for any domain and thereby impersonate websites.
A researcher discovered the problem on 17 October. Chrome and Firefox blocked the certificates that same day, with Apple and Microsoft following in the days after. Google is also removing the underlying root certificate emSign ECC Root CA G3 from Chrome. eMudhra says only one intermediate certificate was in use and that no customer certificates were issued with them. Around 30,000 certificates still have to be migrated, and the company is leaving the global market for TLS certificates, Inc42 writes.
In a review dated 26 October, the Go team explains why it used an emergency procedure for the first time. On Linux, Go checks certificates with its own verifier, which has no built-in revocation mechanism. Less than 7.5 hours after the report, Go 1.27.3 and 1.26.10 were online, rejecting the affected certificates. The release process itself took almost 4.25 hours because of bottlenecks that had never surfaced before. Next time the team wants to announce such a release in advance, and it wants the same revocation support on Linux as on Windows and macOS. Anyone running Go programs that make TLS connections should rebuild them with the latest versions.
Java had to adjust too, InfoQ reports. Oracle published a security alert, and Azul released an out-of-cycle update on 21 October that blocks the certificates in the JDK. Azul points out that Java does not check certificate revocation by default, so a Java application may accept a forged certificate as long as the JDK does not block it. Speaking to CSO Online, an analyst advises companies to check older Java applications in particular, as well as payment platforms, mobile apps and network equipment with their own trust list.