Google’s eMudhra Certificate Removal: What Website Owners in Africa Need to Know

What the eMudhra Certificate Incident Means for Website Security

Google is preparing to remove emSign ECC Root CA - G3 from the Chrome Root Store after private keys associated with eight eMudhra intermediate certificate authorities were found to be cryptographically weak. The decision could cause some legitimate websites to display certificate errors in Chrome unless their operators replace affected TLS certificates.

The incident has also taken on a wider significance since eMudhra announced on 22 October 2026 that it would withdraw from the global SSL/TLS certificate business. The company says its G1 root certificates remain active and that it is offering certificates issued by Sectigo as an alternative for customers.

For website owners, these developments raise two related but separate questions: whether a current certificate depends on the specific root Google is removing, and whether a longer-term migration to another certificate authority is necessary.

Google expects the root removal to reach devices relying on the Chrome Root Store on 27 October 2026, with earlier availability through Chrome's prerelease channels. Operators should establish their certificate dependencies before that change takes effect rather than wait for visitors to encounter security warnings.

How weak certificate keys created a security risk

Digital certificates help browsers establish that a website is presenting credentials issued through a trusted certificate authority (CA). A certificate authority's intermediate certificates can authorise the issuance of certificates for individual websites, while root certificates sit higher in the trust hierarchy.

The security of this arrangement depends on the secrecy of private keys. If an attacker can recover an intermediate CA's private key, they may be able to create fraudulent certificates for domains they do not control. A client that still trusts the compromised authority could then accept a certificate that should never have been issued.

According to Google's security announcement, the Chrome Root Program received a report on 17 October concerning eight eMudhra subordinate CA certificates whose private keys had been generated with insufficient cryptographic randomness.

Google subsequently blocked the public-key identifiers associated with the affected TLS intermediates through Chrome's Certificate Revocation List Set (CRLSet). The measure did not require users to install a new Chrome version or restart the browser. Google also distributed equivalent protection to Android devices and Chromebooks through Google Play services.

The incident did not establish that every eMudhra certificate had been compromised. In its incident statement, eMudhra said none of the eight affected intermediate authorities had issued end-entity certificates and that the weakness arose during a key-generation procedure. The company also stated that its root private keys were not affected.

Google's response nevertheless extended beyond blocking the eight intermediates. It removed emSign ECC Root CA - G3 from the Chrome Root Store to protect other consumers of that store that might not receive CRLSet updates.

This is important because a browser can stop trusting a compromised issuing key without every other application automatically receiving the same protection.

Why Chrome's root-certificate decision matters

Removing a root certificate changes the trust relationship for certificates that depend on it. Even when a website's own certificate has not expired and its server is configured correctly, Chrome may reject the connection if the certificate chain relies on a root that the browser no longer trusts.

This does not mean that the root certificate's private key was itself compromised. Google's announcement identifies the weakness in the subordinate certificates and explains that removing the root is an additional protective measure.

It also does not mean that all eMudhra certificates will stop working simultaneously. The immediate Chrome action concerns emSign ECC Root CA - G3. Other certificates may have different issuing chains and trust relationships, although eMudhra's subsequent business decision means customers should also seek clarity about the future of their existing certificates.

In its 22 October update, eMudhra said it would withdraw from the global SSL/TLS certificate business. The company also said its G1 root certificates remained active and that it was making certificates issued by Sectigo available as an alternative.

Website operators should therefore avoid making assumptions based on the issuer's name alone. The relevant questions are which root signs the current chain, whether that root remains trusted by the clients the website serves, and what replacement arrangements the certificate provider has confirmed.

What African businesses should consider

For businesses in Nigeria and elsewhere in Africa, the incident is principally a certificate-management issue rather than evidence of a widespread regional security failure.

An organisation does not need to be based in India, have a direct commercial relationship with eMudhra or operate a particularly large website to be affected. What matters is whether its certificate chain depends on the root being removed and whether its software clients trust that chain.

A Nigerian online retailer, a financial technology company serving customers in several African markets or an organisation operating a customer portal should establish which certificate authority issued its certificate and which root certificate completes the chain. If the chain depends on emSign ECC Root CA - G3, the operator should arrange a replacement before the announced Chrome change takes effect.

Organisations that use managed hosting, content delivery networks or external certificate-management services should ask their providers to confirm whether any affected certificates are deployed on their behalf. The same check should cover APIs, subdomains and other endpoints that may be managed separately from the main website.

Companies should also consider the software used by their customers and employees. Some applications use their own certificate bundles or rely on operating-system trust stores rather than receiving the same updates as Chrome. A browser update alone should not be treated as proof that every application has been remediated.

There is currently no evidence in the cited incident reports that African websites as a group have been affected. Businesses should check their actual certificate chains and act only where a dependency is confirmed, avoiding unnecessary replacements or needless alarm. This is part of a broader approach to online security: while TLS certificates help browsers verify website identities, passkeys help users authenticate securely. TechView Africa’s guide to passkeys and how they improve authentication security explores the authentication side of protecting online services.

How to check whether your website is affected

You can check your website’s certificate chain without being a cybersecurity expert. Here’s how to find out whether it relies on the root certificate Google is removing from Chrome.

1. Open the SSL Labs certificate checker. Visit the Qualys SSL Server Test and enter your website’s domain name, such as example.com. Click Submit and wait for the report to finish.

2. Find the certificate chain. In the results, look for the Certification Paths section. Review the certificate chain for each server endpoint listed in the report.

3. Search for the affected root. Use Ctrl + F on Windows or Command + F on Mac and search for the exact name: emSign ECC Root CA - G3. If it appears as the root in a certification path, that endpoint may be affected by Chrome’s planned removal. If the results are unclear, ask your certificate provider to confirm the chain; not finding the name in the report alone is not proof that every endpoint is unaffected.

4. Contact your hosting provider or certificate authority. If your website relies on this root, ask for a replacement TLS certificate that chains to a root trusted by Chrome. Since eMudhra has announced its withdrawal from the global TLS certificate business, also request a migration plan covering installation and future renewals.

5. Test your website after replacement. Check the site in Chrome and test important subdomains, payment flows and APIs. Monitor for certificate errors, and never advise visitors to bypass browser security warnings.

Google says website operators whose certificates chain to this root should acquire and install a replacement from another hierarchy included in the Chrome Root Store.

Our Recommendation

TechView Africa recommends that website owners verify their certificate chains now and contact their certificate providers if any service relies on emSign ECC Root CA - G3. Where a replacement is required, install a certificate from another hierarchy trusted by Chrome and test the result across the browsers, operating systems and applications that customers use.

Organisations holding other eMudhra certificates should not assume that every certificate has been compromised or will immediately stop working. They should, however, request clear guidance about continued support and replacement timelines in light of the company's announced withdrawal from the global TLS certificate business.

For ordinary users, keeping browsers and devices updated remains the appropriate precaution. If a certificate warning appears, do not disable security checks or proceed through the warning simply to access a website.

The wider lesson is that website security depends on more than installing HTTPS once. Certificate authorities must generate and protect keys correctly, browsers must maintain trustworthy root stores, and organisations must be prepared to replace certificates when the trust relationships underpinning their services change.