A website can appear to have an HTTPS connection even when the software is trusting it incorrectly. The eMudhra incident illustrates why connection security also depends on certificate authorities and updates to the tools we use.
Status as of October 26, 2026. The measures below distinguish protections announced by vendors from checks needed in each environment. Official advisories may change.
What happened?
Private keys for eMudhra intermediate authorities were generated with insufficient randomness. They could be recovered from public information and used to sign forged certificates. The problem concerned key generation, not evidence that the P-384 cryptographic algorithm had been broken. CERT-In advisory.
Apple identifies eight affected intermediate authorities: six for TLS and two for code signing. Each TLS intermediate had two certificates, including a Sectigo cross-signature: twelve TLS certificates, but six TLS keys. Apple’s explanation.
On October 26, eMudhra acknowledged a script error. The company says its investigation found no compromise of its infrastructure or customer data and announced that it would publish its findings. These issuer statements do not establish that no exploitation occurred elsewhere. eMudhra statement.
Root, intermediate and website certificates: what does each do?
Software opening a connection must decide whether to trust the certificate it receives. A typical chain connects three roles, described in the X.509 certificate standard:
Root authority: provides a trust anchor recognized by the system or application.
Intermediate authority: receives delegated certification authority and signs other certificates. A chain may contain several intermediates.
Website certificate: associates a public key with the service’s domain names, among other information.
Verification examines this chain and the software’s trust rules. In this incident, the weak keys belonged to intermediates. Subsequently removing trust in a root is a protective measure; it does not mean that the root’s own private key was discovered. For the trust-anchor concept, see the DigiCert documentation.
What was the actual risk?
An attacker intercepting a connection could impersonate the intended website and read or alter exchanges if the software still accepted the compromised chain. This did not automatically grant access to the legitimate server or its database. Mozilla’s analysis.
Distinguish the ability to attack from an observed attack. An inventory of vulnerable software does not prove exploitation. Conversely, the absence of a visible alert does not validate its configuration. Red Hat describes continued trust in the affected authorities and the attacker’s network position among the conditions for exposure. Red Hat advisory.
How could an attack unfold?
Imagine an employee opening her company’s portal. She enters the right address, but her connection passes through equipment controlled by an attacker. The following scenario illustrates the possible mechanism; it does not describe an attack observed at Nuagerie.
- Obtain signing power. A compromised intermediate key allows signatures that the client might still accept.
- Prepare a false identity. The attacker creates a server key and a certificate bearing the portal’s name.
- Intercept the connection. Access to the network path remains necessary, for example through a compromised gateway. The certificate alone redirects no traffic.
- Have that identity accepted. The client must still consider the chain valid and not block the certificate under its other rules.
- Sit between the two parties. The attacker can establish a second connection to the real portal and relay the exchanges, becoming an endpoint of each encrypted connection.
This explains how encryption can work while the other party is an impostor. OWASP describes the two-connection model; X.509 defines certificate-path validation.
Key dates
October 17, 2026: report received and blocking in Chrome and Firefox. Google, Mozilla.
October 18: intermediates revoked, according to CERT-In.
October 19: blocking of affected TLS certificates began on Apple devices. Apple.
October 20 and 21: public advisories; on October 21, Mozilla corrected blocking enforcement on some Firefox Android clients. Mozilla.
October 27: the date Google set for removing emSign ECC Root CA - G3 from Chrome on all devices, after prerelease channels. As of October 29, Google had not published a separate rollout confirmation; a site still chained to this root should move to a new chain now. Google.
Before blocking, Google had found no TLS certificates from those six intermediates in Certificate Transparency (CT) logs. This additional protection applies to clients that enforce CT. Google’s explanation.
What should you do?
If you use a computer or phone
Install available updates for your operating system, browser and applications. Restart an application if prompted. If a certificate warning appears, note the address, message and time, then contact the responsible team through a known channel. Our certificate-warning guide explains the initial checks.
Apple distinguishes its Safari protections from command-line tools or applications using other trust lists. Checking the browser alone therefore cannot establish protection across the device. Scope of Apple’s protections.
If you are responsible for a website
Ask your host or administrator to check the chain actually served. For a website chained to this G3 root, Google requires a new trusted chain. This instruction does not apply to every website. Google’s guidance.
Prepare a list of your domains, subdomains, hosting services and any CDNs. Identify who can make changes and request confirmation of the result afterwards. Our guide to setting up and maintaining HTTPS helps organize these steps.
If you manage servers, applications or containers
Identify the component that actually validates certificates: the operating system, runtime, HTTP library or bundled trust list. Cloudflare notes that updating an SDK alone may leave the underlying verification policy unchanged. Its recommendations also cover container images and dependencies. Cloudflare’s technical guidance.
We recommend tracking four elements for each change: the affected component, the fix applied, its actual deployment and a test of relevant connections. Include scheduled tasks and integrations, even if nobody opens them in a browser. Consult instructions for your products, including the Red Hat measures.
Do not disable TLS verification to clear an error after an update. Cloudflare explains that this removes the authentication protection you need. Have the certificate, chain and trust configuration examined. Cloudflare.
For technical teams: CAA, transparency and TLS
A DNS CAA record identifies which authorities may issue for a domain. It is checked during issuance, not enforced as a cryptographic lock on the signing key. We therefore infer that someone signing directly with a compromised key bypasses this normal check. How CAA works.
Certificate Transparency makes issuance observable. A logged certificate is not necessarily legitimate. Rejecting a certificate without CT proof also depends on client policy; logging, blocking and revocation serve different purposes. CT principles.
Possessing a certification key alone also does not decrypt previously recorded TLS 1.3 sessions established with a correctly executed ephemeral key exchange and subsequently erased session secrets. This forward secrecy does not protect a new session established with an accepted impostor. TLS 1.3 properties.
Do you need to buy another certificate?
The deciding factors are an accepted chain and its proper management. A paid certificate does not fix a remote application’s trust list. Free certificates can suit a business website: Let’s Encrypt offers domain validation, multiple names and wildcard certificates. Let’s Encrypt FAQ.
Nuagerie includes free SSL with services that require or support it. Commercial certificates can be considered for specific requirements on a custom quote. The guide to choosing an SSL/TLS certificate distinguishes those needs from incident response.
Help suited to your environment
Unsure whether this concerns your hosting, computers or an application? Our team can help clarify the scope, responsibilities and next checks. A working connection or a provider’s name alone cannot confirm protection across an entire environment.
For an existing service, find our contact details on the support page. To arrange a review of your services, let’s discuss your needs. Prepare the domains, affected software and observed messages; do not send a private key in an ordinary support request.