Eight eMudhra Intermediate Certificates Were Compromised. What It Means for Your Site
On October 20, 2026, Mozilla disclosed that the private keys behind eight eMudhra intermediate certificates had been compromised: six for websites (EM DV, OV and EV TLS CA - G3B and G3C) and two for code signing. Each existed twice, once under eMudhra's own roots and once cross-signed by Sectigo's AAA Certificate Services root, making 16 certificates. Mozilla blocked all of them in Firefox through OneCRL less than three hours after the October 17 report, eMudhra revoked its copies on October 18 and Sectigo revoked its copies on October 19, all with the reason CA compromise. Sites with certificates from these intermediates need new certificates, because no chain through them is trusted.
On October 20, 2026, Mozilla disclosed that the private keys behind eight eMudhra intermediate certificates had been compromised (Mozilla's announcement on dev-security-policy). A community member reported it to Mozilla on Saturday, October 17, at 20:06 UTC. Less than three hours later, Firefox was blocking all of them. eMudhra and Sectigo have since revoked every one.
This is a different kind of incident from the revocations we usually write about. When GoDaddy or HARICA revoke certificates, the problem is paperwork: something inside the certificates does not match the rules. Here, the keys a CA uses to sign certificates were exposed. In Mozilla's words, they "could allow attackers to issue fraudulent HTTPS certificates for websites they do not control."
What was compromised
Your site's certificate is not signed directly by a root that browsers trust. It is signed by an intermediate certificate, and the intermediate is signed by the root. The CA keeps the intermediate's private key and uses it to sign customer certificates. Whoever holds that key can sign certificates that look exactly like the CA's.
Eight eMudhra intermediates are affected. Six are for websites, issued to eMudhra's Dutch company (eMudhra BV) and its US company (eMudhra Inc). Two are for code signing.
| Intermediate | Used for |
|---|---|
| EM DV TLS CA - G3B, EM DV TLS CA - G3C | Websites (DV) |
| EM OV TLS CA - G3B, EM OV TLS CA - G3C | Websites (OV) |
| EM EV TLS CA - G3B, EM EV TLS CA - G3C | Websites (EV) |
| EM OV CS CA - G3B, EM OV CS CA - G3C | Code signing |
Each one exists twice. One copy is signed by eMudhra's own roots. The other is signed by Sectigo's older AAA Certificate Services root, which gave eMudhra's intermediates a path to trust in more places. Both copies use the same key, so both are compromised: 16 certificates in all. Mozilla has not yet said how the keys were exposed and says it will share more as soon as it can.
What has happened since
| When (UTC) | What happened |
|---|---|
| October 17, 20:06 | A community member reports the compromise to Mozilla. |
| October 17, 22:59 | Firefox blocks all 16 certificates through OneCRL, Mozilla's central list of revoked certificates. Users do not need to update or restart Firefox. |
| October 18, 09:24 to 09:38 | eMudhra revokes its eight copies, giving "CA compromise" as the reason. |
| October 19, 10:35 | Sectigo revokes the eight copies its root signed, for the same reason. |
| October 20 | Mozilla discloses the incident and updates NSS, its list of trusted roots, to remove the root that signed these intermediates. Mozilla says this is not needed for Firefox, but protects other software that uses Mozilla's list without OneCRL. |
The revocation times come from the list of affected certificates Mozilla attached to its announcement. We also checked the CCADB, the database every major root program uses for CA records. On October 20 it listed all 16 as revoked and as not trusted by Mozilla, Chrome, Apple or Microsoft.
If your certificate came from one of these intermediates
Click the padlock in your browser and look at who issued your certificate, or run a free scan. If the issuer is one of the six website intermediates above, your certificate is signed by a revoked intermediate. Firefox already refuses it, and other browsers and devices will follow as their own lists update.
Changing the chain your server sends will not help, because every copy of these intermediates is revoked. You need a new certificate, issued from an intermediate that is not on this list, and installed everywhere the old one runs. Then scan the site again to confirm the new certificate is the one being served.
If you sign software with a certificate from one of the two code-signing intermediates, contact eMudhra about re-signing.
Why it matters even if you never bought from eMudhra
A compromised intermediate key can sign a certificate for any domain, including yours. That is why this was fixed in hours rather than days. Software that checks the revocation lists now refuses anything signed by these intermediates. The gap is software that does not check revocation and still trusts the roots behind them. That is the gap Mozilla's NSS update is meant to close for software built on Mozilla's list.
There is one thing you can check yourself. Chrome and Safari only accept a certificate that has been published in the public Certificate Transparency logs. Search the logs for your domain, for example on crt.sh, and look for certificates you did not ask for, especially any issued by the intermediates above.
How TLS Radar handles this
Every TLS Radar scan, including the free one, checks every certificate your server sends against the CCADB's list of revoked intermediates. These 16 are on it. If your chain runs through one, the scan reports a high-severity finding, which lowers the grade to D. If the site is one you monitor, you get an alert that names the intermediate and explains how to fix it.
What a scan shows
To show exactly what you would see, we passed a certificate chain that runs through EM DV TLS CA - G3B through the same code our scans use, with the CCADB list as it stood on October 20. The site name is made up. The intermediate and the list are real. The scan gave the site a D, with this finding:
Certificate chain runs through an intermediate certificate (CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL) that its certificate authority has revoked and reported to the CCADB. Firefox blocks intermediates reported there once Mozilla adds them to its revocation list (OneCRL), usually in a monthly batch and sooner in an emergency. Serve the chain your CA currently publishes, or reissue the certificate if it was issued by this intermediate.
For a site you monitor, the alert reads:
shop.example.com chains through a revoked intermediate certificate
The certificate chain shop.example.com depends on runs through an intermediate certificate (CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL) that its certificate authority has revoked. Firefox starts blocking sites that use it once Mozilla adds it to its revocation list - usually in a monthly batch, sooner in an emergency - and visitors then see a security warning instead of your site. Serve the chain your CA currently publishes, or replace the certificate if it was issued by that intermediate, as soon as you can.
This time Mozilla acted in under three hours, so Firefox is already blocking these intermediates. And because every copy is revoked, there is no current chain to switch to: the fix here is the second half of that advice, a new certificate.
Checking the revocation lists ourselves
We also pointed TLS Radar's revocation checker straight at the two lists that cover these intermediates, eMudhra's and Sectigo's. For each certificate it downloaded the CA's list, checked that the CA had signed it and that it was current, and looked for the certificate's serial number. All 12 website certificates are on them, revoked for "CA compromise":
| Intermediate | eMudhra copy revoked (UTC) | Sectigo copy revoked (UTC) |
|---|---|---|
| EM DV TLS CA - G3B | October 18, 09:24:32 | October 19, 10:35:36 |
| EM DV TLS CA - G3C | October 18, 09:27:07 | October 19, 10:35:36 |
| EM OV TLS CA - G3B | October 18, 09:37:19 | October 19, 10:35:36 |
| EM OV TLS CA - G3C | October 18, 09:38:46 | October 19, 10:35:36 |
| EM EV TLS CA - G3B | October 18, 09:28:53 | October 19, 10:35:36 |
| EM EV TLS CA - G3C | October 18, 09:30:49 | October 19, 10:35:36 |
These match the times in Mozilla's list. On Business and Enterprise plans, scans run the same check on your own certificate: they read the OCSP answer your server staples, or the revocation list your certificate names, and a revoked certificate drops the grade to F.
A revocation like this does not change anything on your server. The certificate file is the same, and every check you run on the server itself still says it is fine. You only see it by checking from outside, the way a browser does.
Check your chain from outside, the way a browser does
TLS Radar checks every certificate your server sends against the CCADB's list of revoked intermediates on every scan, including the free one, and alerts you when an intermediate behind one of your monitored sites is revoked. On Business and Enterprise plans it also checks the revocation status of your own certificate on every scan.
We also publish a weekly digest of CA compliance incidents drawn from Mozilla's public tracker, so you can watch your CA's record without reading Bugzilla yourself.
Related reading
Frequently asked questions
- What happened with eMudhra's intermediate certificates?
- Mozilla disclosed on October 20, 2026 that the private keys behind eight eMudhra intermediate certificates had been compromised. Those keys could be used to issue certificates for websites the holder does not control. Mozilla blocked the certificates in Firefox within three hours of the report, and eMudhra and Sectigo revoked all 16 certificates that use those keys.
- How do I know if my certificate is affected?
- Look at who issued your certificate, by clicking the padlock in your browser or running a TLS Radar scan. If the issuer is EM DV TLS CA - G3B, EM DV TLS CA - G3C, EM OV TLS CA - G3B, EM OV TLS CA - G3C, EM EV TLS CA - G3B or EM EV TLS CA - G3C, your certificate was signed by a compromised and revoked intermediate.
- Can I fix it by serving a different chain?
- No. Every certificate for these intermediate keys has been revoked, so there is no trusted chain through them. You need a new certificate issued from an intermediate that is not affected, installed everywhere the old one runs.
- Does this affect me if I never bought a certificate from eMudhra?
- Possibly. A compromised intermediate key can sign a certificate for any domain. Software that checks revocation now refuses certificates from these intermediates, but software that does not check could still accept one. Chrome and Safari require certificates to appear in public Certificate Transparency logs, so you can search the logs for your domain, for example on crt.sh, and look for certificates you did not request.
- Does TLS Radar detect a revoked intermediate in my chain?
- Yes. Every TLS Radar scan, including the free one, checks every certificate your server sends against the CCADB's list of revoked intermediates, which includes all 16 of these certificates. A chain through one is a high-severity finding that lowers the grade to D, and monitored sites get an alert.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.