Browsers blocked the eight compromised eMudhra keys within hours. Servers, containers and embedded devices did not get that update, and that is where your exposure sits.
Advisory SW-A004 set out what went wrong at eMudhra. The actions below apply whoever issues your own certificates.
eMudhra announced on 22 October that its Board has decided to withdraw voluntarily from the global SSL/TLS certificate business. According to the company’s statement, that business contributes about 1% of its revenue, the affected authorities were revoked within 14 hours of discovery, and no end-entity certificates were issued from them. Reuters reported the announcement.
The company says its G1 RSA roots will keep serving customers until the transition is complete. According to the announcement, it will also arrange free replacement certificates from partner certification authorities during the transition, keep revocation and certificate-status services running until certificates expire or are replaced, and complete its remaining browser root-program commitments, including a full root-cause report. These are commitments. None has been completed or independently verified.
Organisations that rely on eMudhra certificates now carry a supplier-continuity risk on top of the security risk. Plan migration to independently operated, publicly trusted certificate authorities, and treat any continued use of the G1 hierarchy as temporary. The withdrawal does not change the containment steps in this advisory.
01Executive Overview
What happened, and what to ask your team
eMudhra is a company that issues the digital certificates which let browsers and software confirm that a website is genuine. Eight of its certificates were protected by secret keys so weak that anyone could work them out in under a second. Someone holding those keys could build a fake website that software would accept as real, provided they could also intercept the victim’s connection.
Browser makers fixed this within hours. Other software did not get an automatic fix. That includes the servers and applications that run business systems. Each one has to be updated by whoever looks after it.
No source reports that anyone has used the keys against a customer. That finding is incomplete, because much software does not keep the records that would reveal it. India’s national cyber agency reports that eMudhra’s Indian digital signature and eSign services are unaffected. This incident concerns its certificates for websites and software. On 22 October eMudhra announced that it will withdraw from that business.
One deadline is fixed. From 27 October, Google Chrome stops trusting the affected certificate chain, and websites that use it will show errors until their certificates are replaced.
Are our systems updated?
Browsers, servers, containers and devices. Ask for the answer per system, not as a general assurance.
Which of our websites are affected?
Ask which use certificates from the affected chain, and whether each will be replaced before 27 October.
Which suppliers have not confirmed?
Ask who holds our customer connections and data, and whether they have confirmed their own status in writing.
What is the evidence?
Ask for test results that show old certificates being rejected and new ones working. A renewal receipt is not proof.
02Why It Reaches You
Your clients’ trust stores decide your exposure
Six of the eight compromised keys belong to TLS certificate authorities and two to code-signing authorities. Google reports that the keys were generated with insufficient randomness, which lets anyone forge trusted HTTPS certificates against clients that still trust those authorities.
Red Hat sets out the conditions for harm in its bulletin RHSB-2026-012. A system must trust the compromised intermediates, an attacker must hold the keys, and the attacker must be able to intercept the connection. Red Hat adds that the compromise alone does not mean any system has been attacked.
Every client that trusts the affected authorities is exposed, whoever issued your own certificates.
Chrome and Firefox blocked the keys on 17 October. Most applications do not receive that kind of emergency update. Cloudflare notes that browser maintainers could act quickly because they manage one application and have quick-revocation mechanisms. Servers, API clients, proxies, containers and devices depend on whoever maintains their trust stores.
Clients accept fraudulent certificates
Any TLS client that still trusts the compromised intermediates, including their cross-signed copies, could accept a forged certificate. This covers outbound HTTPS from application servers, API integrations, proxies and remote-access software.
The compromised TLS intermediates are EM DV TLS CA, EM OV TLS CA and EM EV TLS CA, each in versions G3B and G3C. The two code-signing intermediates are EM OV CS CA G3B and G3C.
Legitimate certificates stop working
Mozilla has removed emSign ECC Root CA – G3 from NSS, in release 3.131.1. Google is removing it from the Chrome Root Store, and the removal is expected on devices on 27 October 2026. Legitimate certificates that chain to that root will fail, even though their own keys are not compromised.
The two risks need separate fixes. Risk A is a trust-store problem on your clients. Risk B is a certificate-replacement problem on your servers.
India’s CERT-In separates eMudhra’s two businesses in advisory CIAD-2026-0050, issued on 21 October. This incident concerns the certificates that browsers and operating systems trust. CERT-In says that, according to reports, eMudhra’s domestic Digital Signature Certificate and eSign infrastructure was unaffected, because it uses distinct keys generated under different compliance frameworks. It also states that the weakness arose in key generation and not in the P-384 algorithm.
Sources: Google, Mozilla Bug 2083449, Red Hat, Cloudflare, Ubuntu, Go, CERT-In.
03The Next 24 Hours
Find the exposure, then update the trust stores
Open the test site published by Mozilla’s Dennis Jackson in every browser your staff use. It tries to connect to test sites that carry certificates from the compromised intermediates. A browser that has blocked them refuses the connection. A browser that connects still trusts the compromised authorities and needs an update.
The page also gives instructions for command-line tools and other non-browser clients. Run those checks too, because a browser result says nothing about a server-side client.
Next, build an inventory of every publicly trusted TLS certificate you operate: websites, APIs, load balancers, CDN and proxy configurations, Kubernetes ingress, VPN gateways, remote-access systems and third-party services where you control the certificate. For each one, examine the full chain and the trust anchor the actual client uses. Prioritise chains that involve emSign ECC Root CA – G3, including those issued through InCommon Intermediate CA – OVG3C and DVG3C.
An initial check, which shows the chain a server sends:
Servers often omit the root, so this is only a starting point. A complete check verifies the path the real client builds. An ECC certificate is not affected merely because it uses elliptic curves. The issuing hierarchy and the trust path decide.
Then list every system that uses public CA certificates to authenticate remote services, and update it.
Ubuntu
USN-8944-1 removes emSign ECC Root CA – G3 from ca-certificates and refreshes the bundle to Mozilla’s 2.90 release. It covers 22.04, 24.04, 26.04 and 26.10.
Red Hat
RHSB-2026-012 rates the impact Important and tracks RHEL as CVE-2026-114406. The bulletin was updated on 22 October and does not yet list fixed packages. It points to a knowledge-base article on disabling the Comodo AAA root, which signed some of the compromised intermediates.
macOS
Apple has blocked the intermediates at operating-system level since 19 October. The built-in curl, git, python3, perl, ruby and openssl read a separate file, /etc/ssl/cert.pem, which does not check revocation and has not been updated. The test site gives a command that removes the affected roots from that file, and a separate fix for the built-in pip.
Windows
Microsoft has shipped blocks through automatic certificate trust list updates since 20 October. Machines that receive them need nothing more. For offline machines or those with updates disabled, the test site offers a script that blocks the 16 certificates locally. It advises against the script on enterprise-managed devices, so speak to your IT team first. Applications with their own CA bundles still need updates.
Go
GO-2026-6809 (CVE-2026-111943) adds a denylist in crypto/x509 that makes Verify fail for the known intermediates. It is fixed in Go 1.26.10 and 1.27.3. Rebuild and redeploy compiled applications with a fixed toolchain.
Java and Perl
Red Hat lists CVE-2026-91403 for Java and CVE-2026-113812 for Perl Mozilla::CA. Check runtimes with their own cacerts stores, and any Python environment that ships its own CA bundle.
The test site also tabulates patched versions for Debian, Fedora, Alpine, Arch, FreeBSD, Node.js, Python certifi, pip, uv, Rust, Deno and others. For Linux distributions that have not shipped a fix, it lists manual distrust commands for expert users and advises against them for ordinary users.
Applications can keep their own certificate stores or use TLS libraries that ignore the operating system’s trust decisions. Cloudflare tells developers to look beneath the SDK, because updating an SDK may not change the verification policy underneath it. Rebuild container images that bundle trust stores, and review embedded appliances, VPN clients, third-party agents, security gateways and TLS inspection platforms.
Where your trust infrastructure can block individual intermediates, block them by public key, as Chrome did. Chrome’s block works on the SPKI hash, so it covers every certificate that shares a compromised key. A block by subject name can miss the cross-signed copies. Where intermediate-level blocking is not available, weigh removing the relevant roots. Legacy chains that run through AAA Certificate Services need care, because removing that root can break other legitimate services. Test dependencies and keep an approved restoration plan before any emergency trust-store change. For systems that cannot be updated, restrict their network exposure until they can.
04Replace Certificates
Move off the G3 hierarchy before 27 October
Google tells website operators to install a certificate from another hierarchy in the Chrome Root Store before the removal. For business-critical services, use a different CA operator while the rest of eMudhra’s infrastructure is under review. Google says it is examining eMudhra’s remaining CA certificates, and Mozilla has said it is not removing emSign Root CA – G1 at this time. With eMudhra now leaving the global SSL/TLS business, weigh that when you choose a replacement provider.
- Obtain and install the replacement certificate with the correct intermediate chain.
- Confirm it is valid for every required hostname and service.
- Deploy it across all servers, load balancers and geographic endpoints.
- Test against production clients, including older operating systems and runtimes.
- Retire the old chain configuration and record the migration.
Do not assume automated renewal will move you in time. An eMudhra representative told Mozilla that about 30,000 certificates need migration, around 97% of them issued through ACME. Standard renewal schedules can leave a certificate unchanged until its normal renewal window, and the switch may need issuer selection or manual action. Start the renewal yourself, verify the deployment, and confirm the new chain is accepted by the clients you serve. A migration is complete when production presents the new chain and clients validate it.
Most affected certificates were not issued by eMudhra’s own intermediates. Based on certificate transparency data as of 21 October, quoted in Mozilla’s incident record, about 30,800 unexpired precertificates chain to emSign ECC Root CA – G3. Of those, 30,791 were issued by two Internet2 and InCommon intermediates, InCommon Intermediate CA – OVG3C (23,806) and DVG3C (6,985). Cornell identified more than 300 affected certificates on its own estate.
These certificates need migration because the G3 root is being distrusted. No source reviewed reports the InCommon intermediate keys as compromised, and Cornell’s alert records that eMudhra does not believe they were. Your certificate is affected if its chain runs from InCommon Intermediate CA – OVG3C, to emSign Root TLS CA – G3, to emSign ECC Root CA – G3.
Cornell advises requesting a new certificate with an RSA key instead of an ECC key, because RSA certificates use eMudhra’s unaffected root. The University of Michigan lists the affected issuers as OVG3C, DVG3C and EVG3C, says InCommon certificates issued through Sectigo are not affected, and warns that RSA certificates from the same service may be affected later. Its alternatives are a new certificate from Let’s Encrypt or placing the site behind Cloudflare as a temporary measure.
05Prove It Works
Test the path each application uses
In an authorised, isolated environment, confirm that each TLS verifier rejects chains containing the compromised intermediate keys. Use a vendor-provided test service where one exists.
Confirm that the replacement certificates validate and that business-critical connections work, without bypassing TLS protections.
Cover browsers, command-line clients, server-side libraries, proxies, managed devices and software with embedded certificate stores. The test site from section 03 lists patched packages and gives non-browser instructions. Cloudflare warns that a browser test does not prove a background service is protected, and neither does a curl test if the application uses a different verifier.
For each system, record the application version, TLS library, effective trust store, test result and owner. When errors appear after patching, do not disable certificate validation or add blanket trust exceptions. That removes the protection the updates restore.
06Look for Misuse
Investigate without assuming a breach
The compromise of CA keys does not show that your network was attacked. Google reports that no TLS certificates chaining to the six affected TLS authorities were logged to Certificate Transparency before it blocked them, so no fraudulent certificate from those authorities could have been used against clients that enforce CT. Cloudflare found no active exploitation on its services.
Two limits apply. Many applications do not enforce CT, and many clients skip revocation checks. A fraudulent certificate could therefore have gone unlogged and unnoticed against those clients. Review your telemetry for unexpected certificate chains, issuers you have not seen before, validation anomalies, unexplained proxy or gateway changes and certificate inconsistencies recorded by endpoint or network tools. Give priority to administrative access, authentication flows, financial transactions and privileged API integrations.
The keys have been recoverable since the 30 April 2025 key ceremony, so look back to that date where your logs allow. State the limits of the logs in your findings. Treat any credible sign of a fraudulent certificate being accepted as an incident under your normal response procedure.
07Report and Schedule
What leadership should see
Assign owners across infrastructure, endpoint, application, PKI and third-party risk. Ask suppliers that cannot give a verified remediation status for a written position, and escalate those that do not respond. Prioritise identity infrastructure, payments and financial services, healthcare, critical infrastructure, remote access and high-value API integrations.
| Measure | Evidence expected |
|---|---|
| Certificate exposure | Complete inventory of services that depend on the G3 hierarchy |
| Client protection | Verified status of trust stores and applications |
| Certificate migration | Replaced, validated and outstanding counts |
| Service availability | Successful service and client compatibility tests |
| Unsupported systems | Documented exceptions, isolation and owners |
| Investigation | Findings, telemetry limits and follow-up |
| When | Outcome required |
|---|---|
| Now, 22 October | Start incident coordination, test every browser against the test site, identify exposed client platforms, deploy available trust-store updates and begin certificate replacement |
| Within 24 to 72 hours | Validate critical TLS clients, rebuild affected applications and containers, finish priority migrations and document exceptions |
| Before 27 October | Complete G3 migration on production services and confirm compatibility ahead of the Chrome Root Store change |
| After containment | Finish the retrospective investigation, supplier reviews and improvements to certificate lifecycle and trust-store management |
If you cannot meet a deadline, record the affected services, apply risk-based containment and escalate the residual risk to executive management.
08What to Avoid
Six assumptions that cause incidents
- A valid expiry date means the certificate stays trusted.
- CRL and OCSP infrastructure is enough. Many TLS implementations do not check revocation reliably.
- Browser updates protect server-side applications.
- Disabling TLS verification, clicking through warnings or re-adding a distrusted CA is an acceptable way to restore a service.
- A successful renewal proves every endpoint and application is protected.
- The incident is contained before the controls have been tested.
09Signal Watchtower Assessment
Trust is a dependency you manage
Browser vendors showed that a compromised authority can be blocked within hours when a fast trust-update channel exists. Most enterprise systems have no such channel, and their exposure continues after the mainstream browsers are protected. The immediate task is to remove trust in the compromised keys, move services off the distrusted hierarchy and verify that every critical system is protected. The longer task is to treat certificate inventories, trust-store updates and independent path validation as standing controls, and to ask suppliers how they would handle the next one.
Browsers were protected within hours. Your servers, containers and devices are protected once someone updates them.
10Supplier Assurance
Check the certificate, then check who issued it
eMudhra hosts an ISO/IEC 27001:2022 certificate on its own website. It records the following.
| Certificate holder | eMudhra Limited |
| Certificate number | SCK/05/EML/23/91/2406 |
| Issued by | SCK Certifications Pvt. Ltd. |
| Initial registration | 5 May 2023 |
| Expiry | 4 May 2026 |
| Scope | Functioning as a certifying authority, providing eSign service, and developing and delivering PKI, identity and authentication platforms, document signing and data analytics |
As of 22 October 2026, the published certificate is past its stated expiry date. We have not seen a replacement covering the period after 4 May 2026. That does not show the certification has lapsed, because eMudhra may hold a renewed certificate that it has not published.
The certificate carries the International Accreditation Service (IAS) mark and the number MSCB-244. IAS’s register of cancelled customers lists SCK Certifications Private Limited under MSCB-244, in Uttar Pradesh, India, with a cancellation date of 17 October 2023 and the reason “Administrative”. IAF CertSearch shows most of SCK’s IAS scopes as withdrawn, including one ISO/IEC 27001:2022 entry, and another ISO/IEC 27001:2022 entry as active. A separate entry lists SCK under the United Accreditation Foundation (UAF) with active ISO/IEC 27001:2022 accreditation, and SCK’s website says it is accredited by UAF. The IAS cancellation and the UAF accreditation are separate records. Neither establishes fraudulent certification. These records show a change in accreditation. They do not show any fault in the audits or in the validity of a particular customer’s certificate. Confirm eMudhra’s current certification status through SCK and the accreditation bodies’ own registers.
ISO 27001 certification and WebTrust assurance are separate activities. CERT-In names BDO International Limited as the WebTrust auditor for eMudhra’s international certificate operations.
Confirm that each security certification and audit report is current, covers the service you buy, and is backed by valid accreditation where one is claimed. Check the scope, the validity dates, the certification body’s accreditation, the audit coverage and the verification of corrective actions. A certificate or report shows that an audit took place. It does not show that the controls work.
Certification and audit documents are supporting evidence. Cryptographic trust depends on controls that can be verified.
11Sources
- Google Chrome and Android Security Teams: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 October 2026
- Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20 October 2026
- Mozilla Bugzilla 2083449: eMudhra, Private key compromise of Intermediate Certificates
- oss-security: NSS 3.131.1 Release, Important Security Updates, 20 October 2026
- Mozilla dev-tech-crypto: NSS 3.131.1 release announcement
- CERT-In: Advisory CIAD-2026-0050, Compromise of eMudhra Intermediate CA Certificates, 21 October 2026
- Ubuntu: USN-8944-1, ca-certificates update, 20 October 2026
- Red Hat: RHSB-2026-012, Certificate compromise – eMudhra, updated 22 October 2026
- Go vulnerability report GO-2026-6809 (CVE-2026-111943), 21 October 2026
- Cloudflare: 8 eMudhra certificates are compromised, 20 October 2026
- eMudhra Intermediate CA Compromise: test site, package list and workarounds, Dennis Jackson, 20 October 2026
- Cornell IT Service Alerts: Some websites may need SSL certificates replaced, 21 October 2026
- University of Michigan Safe Computing: Root Certificate Authorities Distrusted, 20 October 2026
- eMudhra: eMudhra to Exit global SSL/TLS Certificate Business, 22 October 2026
- Reuters: Indian firm eMudhra exits global digital certificates business after vulnerability disclosure, 22 October 2026
- eMudhra Limited: ISO/IEC 27001:2022 certificate SCK/05/EML/23/91/2406
- International Accreditation Service: Cancelled IAS customers
- IAF CertSearch: SCK Certifications Private Limited (IAS accreditation records)
- IAF CertSearch: SCK Certifications Private Limited (UAF accreditation records)
- SCK Certifications: Accreditation
- Signal Watchtower Advisory SW-A004: eMudhra Certificate Keys, 255 Guesses
This advisory is based on information publicly available as of 22 October 2026. Follow later guidance from your operating system vendors, browser root programs and certificate providers.
About The Signal Watchtower
Published by Elytra Security. Signal-only intelligence across security, privacy, and AI, with confirmed facts kept rigorously separate from claims. Advisory editions address significant regulatory, policy, and emerging-risk developments as they occur, outside the fortnightly schedule.
Authored by Venkat Mangudi · Founder & CEO, Elytra Security
Integrity. Trust. Clarity.
An ISO/IEC 27001:2022 Certified Company