Eight compromised CA keys raise a fairly fundamental question for many of us in October 2026:
“What’s the point of revoking a certificate if applications keep trusting it anyway?”
Certificate revoked. Still trusted?
On October 30, JetBrains Research informs me – like many others – by email late on a Friday evening about the impact of the eMudhra security incident on its development tools.
On October 30, 2026, JetBrains sends an email about a security update due to compromised eMudhra certificates
Affected products include the IDEs – that is, the software development tools – as well as runtime environments and other products.
It’s important to note: the cause doesn’t lie with JetBrains. Rather, the chain of trust leads back there, just as it did with PHP2Shell.
On October 17, it becomes known that the private keys of eight eMudhra intermediate certificate authorities can be reconstructed by cybercriminals due to insufficient randomness.
This allows attackers to generate certificates that appear trustworthy on inadequately protected systems.
Halloween arrived right on time this year: eight compromised CA keys, and the question of whether revocation really works in practice…
eMudhra is revoking the affected intermediate certificates. Mozilla , Google and other providers respond by revoking certificates via revocation lists and making changes to their trust stores.
“But who checks to see if these measures are actually effective in practice?”
A revocation is not the same as a rejection.
A digital signature proves that certain data has been signed with a specific cryptographic key.
Signatures, however, do not prove that we can continue to trust the signed key.
To make an effective decision on a vote of confidence, we need additional information:
- Who issues the certificate?
- Which chain of trust does the application accept?
- Has a certificate been revoked?
- What rules and trust anchors apply at the time of verification?
The answers to these questions vary. Browsers, operating systems, Java runtime environments, and applications with their own certificate stores use different mechanisms.
RTP#28 ENGL Trust Union
Why standards and trust are Europe’s true strengths
How Europe Scales Trust through Standards
🍎 Enjoy on Apple Podcasts: 👉 qrco.de/bgafUC
🎧 Listen on Spotify: 👉 https://qrco.de/bgafTk
Podcast on YouTube: 👉 https://youtu.be/DFw0wqeVe8c
Mozilla blocks the affected certificates via OneCRL. Chrome uses CRLSets. Other applications only receive corresponding protection once their libraries or trust stores are updated.
The fact that browsers block compromised certificates doesn’t mean other applications reject them too. They may use their own trust stores, different methods for validating revocation, or libraries that continue to accept the affected certificates.
Why can this incident affect any website?
The truly alarming part of the eMudhra incident: not a single affected website needs to be compromised itself.
That’s because in this case, no TLS keys belonging to individual websites were stolen. The private keys of eight higher-level intermediate certificate authorities can be reconstructed due to flawed key generation.
Six of these keys are authorized to sign TLS certificates.
This allows an attacker to issue certificates for third-party websites – regardless of which certificate authority their operators actually use for their genuine certificates.
This applies to banking portals just as much as to online shops, Git repositories, and identity providers.
If an attacker can also intercept or redirect network traffic, and the affected application trusts the forged certificate chain, they can impersonate a legitimate server.
The real website itself may remain completely untouched. What’s under attack is the client’s trust decision.
That’s the crucial difference!
eMudhra – 8 Compromised Certificate Authority (CA) Keys – Attack Vectors and Damage Scenarios
To illustrate the attack vectors and damage scenarios, I’ve put together the following graphic for you:
eMudhra – 8 compromised Certificate Authority (CA) keys – attack vectors and damage scenarios – Illustration by Sascha Block – www.rock-the-prototype.com
Mozilla and Google responded as early as October 17 with blocking measures. Modern browsers also widely enforce Certificate Transparency and can reject unlogged certificates.
Two other compromised artifacts were software signing keys. However, software uses different mechanisms within its own, often custom-designed, chain of trust.
That is why it was particularly concerning that command-line tools, server applications, development environments, and applications with their own certificate stores continued to trust these compromised keys.
Even an updated operating system offered no protection in this case, provided that its components—that is, the applications installed with it—were protected, to the extent that they were affected.
So who verifies which certification authorities our applications actually trust—and whether they reliably reject compromised certificate chains?
A publicly accessible website has provided the first concrete test certificate chains and verification endpoints:
https://emudhra.we-have-a-problem.com/
This website provided me with valuable information and served as the starting point for my own tests on Rust-BFF.
What remains much more relevant to me is the question of how we can provide reproducible evidence for such security decisions in the future.
What does this mean for our software?
I took this incident as an opportunity to review the dependencies of my publicly developed Backend-for-Frontend (BFF) for Rock the Prototype.
I am developing this Backend-for-Frontend (BFF) in Rust. Rust is particularly well-suited for this because this programming language prevents many memory and concurrency errors at compile time, enables resource-efficient operation, and provides a robust foundation for later deploying the prototype in production.
In my YouTube Video 🍪 Cookies, Session & Token ❇️ Understand Token Flow in 10 Minutes you’ll learn the technical basics in a way that’s easy to understand yet precise:
- How is an authenticated identity created, who verifies it, and which components can trust it?
- Why a “Backend for Frontend” can securely manage tokens on the server side.
- How DPoP or mTLS can cryptographically bind a token to a legitimate client.
The Backend-for-Frontend handles the login process via OpenID Connect and verifies the user’s identity based on the signed ID token and the associated user data. The BFF manages the authenticated session server-side in Redis. The browser receives a protected session cookie.
Access and refresh tokens remain on the server and are never transmitted to the browser. According to RFC 10017 (BCP 212), “OAuth 2.0 for Browser-Based Applications”, the Backend-for-Frontend pattern is considered the most secure of the OAuth architectures compared there for browser-based applications. The Internet Engineering Task Force (IETF) explicitly recommends the BFF pattern for security-sensitive web applications.
Here, my Rust BFF uses, among others, two relevant components:
- webpki-roots, which provides trusted root certificates.
- rustls-webpki, which validates certificate chains.
Naturally, in their respective current versions, since the new version of rustls-webpki explicitly rejects certificate chains containing certain compromised public intermediate keys.
At the same time, we need to verify the identity binding within an application like my BFF ourselves. We improve the use of updated OIDC signing keys by adding a negative test: if the identities from the ID token and UserInfo don’t match, the BFF rejects the authentication.
These changes are integrated into my public GitHub repository and can be traced through pull requests and automated tests.
However, two further RustSec findings still require a documented risk assessment. The standalone proof that our specific TLS verification path rejects the compromised certificate chains is also still outstanding.
Secure by Design – how should secure processes look like today?
How can trust be demonstrably verified?
For me, this results in a clear technical and organizational requirement.
We need a traceable connection between the components of our software, the cryptographic methods actually in use, the applicable trust rules, and the results of concrete verification.
The OWASP CycloneDX SBOM/xBOM standard offers a solid foundation for this.
A Software Bill of Materials (SBOM) makes the software components and dependencies in use visible.
A Cryptography Bill of Materials (CBOM) can link cryptographic assets such as algorithms, keys, and certificates to these components.
What’s still missing is the actual proof of effectiveness.
Does the application accept a valid certificate chain – and does it demonstrably reject a compromised certificate chain?
Such a test must be reproducible. It must relate to a specific software state and a concrete trust configuration. And its result must remain traceable.
With the Agile Innovation Framework (AIF), I want to map out exactly these connections: from the requirement, through the verification method and observation, to the validated result and the corresponding evidence.
This isn’t a finished audit system yet. But it’s a verifiable path toward developing one transparently, step by step.
Why this goes far beyond TLS
We encounter the same fundamental question with digital identities.
With the European EUDI Wallet or our own d-you, as the digital wallet for Germany is called, new trust relationships are emerging between wallets, issuers of digital credentials, and verifying organizations.
The trust lists, certificates, and status mechanisms used there differ from the Web PKI. However, the underlying technical challenge remains comparable:
A valid cryptographic signature alone isn’t enough. What also matters is whether the issuer is trustworthy for the given purpose and whether the presented credential is valid at the time of verification.
This makes verifying digital trust decisions a task that spans the entire software lifecycle.
Security requires far more than ongoing updates.
Back during the PHP2Shell security incident, we already examined the importance of shared open-source infrastructure and its long-term maintenance.
The eMudhra incident reveals another dimension.
Even when maintainers respond quickly and release security updates, organizations still need to identify which of their systems are affected, integrate the changes in a traceable way, and verify their effectiveness.
This requires technical capability. But above all, it requires accountability, transparent decisions, and verifiable results.
My goal, therefore, isn’t just to develop trustworthy software. I want to make it transparent why we’re justified in trusting it – and how we translate new insights into effective changes.
IT security and effective collaboration require transparency.
That’s exactly why Rock the Prototype exists.
Yours, Sascha Block
Sources and technical references
JetBrains – eMudhra Certificate Authority Incident:
Mozilla – response to the compromised intermediate certificates:
Google – Chrome and Android:
RustSec – webpki-roots:
https://rustsec.org/advisories/RUSTSEC-2026-0381
RustSec – rustls-webpki:
https://rustsec.org/advisories/RUSTSEC-2026-0382
CycloneDX – Cryptography Bill of Materials:
https://cyclonedx.org/capabilities/cbom/
EUDI Wallet – trust verification:
https://eudi-wallet.gov.de/faq
My public BFF prototype:
About the Author:
Sascha Block
I am Sascha Block – IT architect in Hamburg and the initiator of Rock the Prototype. I want to make prototyping learnable and experiential. With the motivation to prototype ideas and share knowledge around software prototyping, software architecture and programming, I created the format and the open source initiative Rock the Prototype.
