Chrome's eMudhra root removal on October 27: what to do

As of October 23, 2026, 02:55 JST (October 22, 17:55 UTC). Every fact that can change carries the time it was checked, in JST (UTC+9). Last changed: October 23, 02:55 JST, Bun 1.4.4 listed as patched.

If your website's certificate chains to emSign ECC Root CA - G3, install a certificate that chains to a different root before Tuesday, October 27, 2026. Google says Chrome's removal of that root "is expected to be released for all devices relying on the Chrome Root Store Tuesday morning, October 27, 2026 PDT."

Chrome's count from Certificate Transparency logs puts about 30,800 unexpired precertificates on that root, 99.9% of them issued by two Internet2 / InCommon intermediates. Let's Encrypt certificates chain to other roots. The eight compromised eMudhra intermediates behind the removal have been blocked in Firefox and Chrome since October 17, in Apple devices since October 19, and on Microsoft platforms since October 20, per the incident page. Status at 02:51 JST on October 23 (17:51 UTC, October 22): the root removal is scheduled, not yet done, and eMudhra said on October 22 that it will withdraw from the global SSL/TLS certificate business.

Below: the dates, a table to see whether your certificate is on that root, the commands to check, what each browser, runtime, and library has shipped, what WordPress, Node.js, and Go do with their own certificate lists, and what to do.

What happened, and when

The private keys of eight eMudhra intermediate certificates "were incorrectly generated by the CA. This means that anyone can recover them from the certificates," per the incident page that Mozilla's Dennis Jackson published on October 20. Google says the weak keys enabled "anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs." Browsers blocked the eight within days. Chrome plans to remove the root above them as well, emSign ECC Root CA - G3, and Google says "Some legitimate certificates chaining to this root will cease to function in Chrome as a result."

Which certificates break

Only certificates that chain to emSign ECC Root CA - G3. The issuer named on your certificate tells you which case you're in. Chrome counted unexpired precertificates, the entries a certificate authority logs to Certificate Transparency before it issues a certificate, as of October 21 (Mozilla Bugzilla 2083449, comment 30, checked 00:46 JST).

Google's words for the first two rows: "website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store." eMudhra says the impact "is contained to a single customer ecosystem in the United States", and that it is issuing that customer's replacements "from an alternate, independently operated, publicly trusted CA hierarchy."

If your site sits behind Cloudflare's automatic certificates, Cloudflare's certificate-authorities page lists Let's Encrypt, Google Trust Services, and SSL.com as their issuers, with Sectigo for backup certificates only (page last updated April 16, 2026; checked 00:46 JST).

How to check who issued your certificate

Replace example.com with your domain:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

Run against letsencrypt.org at 00:57 JST on October 23, with OpenSSL 3.6.3, it printed issuer=C=US, O=Let's Encrypt, CN=YE2. Compare the O= and CN= parts with the table.

To search the whole chain your server sends for the names in question:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -i -E "emsign|emudhra|incommon"

No output means none of those names is in the chain. A failed connection prints nothing too, so run the first command before trusting an empty result. In a browser, the certificate viewer behind the icon at the left of the address bar shows the same "Issued By" names.

To check whether a client on your machine, such as curl, still trusts the compromised intermediates, the incident page gives curl https://dv-g3b-emudhra.we-have-a-problem.com/ and curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/: "A certificate error means the client does not trust the compromised intermediates." Since October 22 it also gives two hosts whose certificates were never logged to Certificate Transparency, curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/ and curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/: "A successful connection to these hosts means the client trusts the compromised intermediates and does not enforce CT" (checked 02:49 JST).

Browsers, runtimes, and libraries

Browsers block through revocation lists they push themselves. Most other software checks certificates against a list it ships or reads from the operating system, and needs an update. The incident page: "many other clients do not consume revocation information and require software updates to ensure they no longer trust the compromised intermediates."

WordPress: the certificate list it ships

WordPress sends its own outgoing HTTPS requests, such as update checks and plugins' calls through its HTTP API, with a certificate list it ships in wp-includes/certificates/ca-bundle.crt. The 7.1 branch's class-wp-http.php sets 'sslcertificates' => ABSPATH . WPINC . '/certificates/ca-bundle.crt'. Visitors' browsers don't use this list, so it has nothing to do with your site's padlock.

On October 21 at 03:15 UTC, WordPress's development trunk replaced the list in a commit titled "Security: Update composer/ca-bundle to version 1.6.0" (ticket #66355), and trunk's file no longer contains emSign ECC Root CA - G3. The 7.1 branch's file, built from Mozilla data "as of: Thu Jul 16 03:12:01 2026 GMT", still contains it (checked 00:46 JST). The latest release is 7.1.3, from October 6 (api.wordpress.org, checked 00:45 JST).

There's no dashboard setting for this. Update WordPress when a release carries the new list. If an outgoing request starts failing with a certificate error, don't turn verification off. Cloudflare: "It's important to not resolve these errors by disabling verification. That would remove the authentication protection these updates are intended to restore."

Node.js and Go

Chrome's and Firefox's blocks don't reach Node.js or Go programs: they check other servers' certificates with their own code, against their own list or the operating system's.

• Node.js 22.23.4, 24.22.1, and 26.12.1, released October 21, carry the fix. The security release lists "ca-cert (eMudhra Intermediate CA Compromise)" for all three lines, and 24.22.1's notes include "tls: reject chains containing blocked public keys" (pull request #66871) and root certificates from NSS 3.131.1. The same releases fix 10 vulnerabilities, covered in Node.js October 2026 security release: what to update.
• Go 1.27.3 and 1.26.10, released October 19 per the Go release history and announced on October 20, fix CVE-2026-111943, "Distrust compromised intermediate certificates in crypto/x509." The CVE record says "On most platforms, Go uses the given system root certificates", so the operating system's update matters too; for the narrower cases, a denylist makes Verify return an error. The Go team's announcement: "We highly recommend immediately upgrading to this release." A Go binary carries the standard library inside it, so rebuild and redeploy after updating Go.

What to do

• If you run a website: check your issuer with the first command above. If it is in one of the two "Yes" rows, install a certificate from another hierarchy before October 27. eMudhra says it "will reach out to affected customers to replace any certificate free of cost from partners through the transition."
• If you run servers or ship software: update the operating system's ca-certificates, your runtimes (Node.js, Go, Bun, Java), and any certificate bundles your code carries (certifi, composer/ca-bundle), then rebuild images and restart. Cloudflare's advice: "Apply the relevant dependency updates, rebuild affected images, and confirm whether applications require a reload, restart, or redeployment."
• If you only use a browser or a phone: the incident page says "Users should update their browsers and operating systems to the latest versions as soon as possible." Restart Android devices to get the block at once.
• Everyone: don't fix a certificate error by turning verification off, with curl -k, rejectUnauthorized: false, or a plugin setting.

What this is not

Other certificate stories from the same weeks, none of them about eMudhra:

The certificates on Convika pages

Pages published on Convika get their certificates issued and renewed without the owner buying or installing one. At 00:49 JST on October 23, a convika.page address presented a Let's Encrypt certificate (issuer YE2, chaining through Root YE and ISRG Root X2 to ISRG Root X1), and convika.com one from Google Trust Services (WE1, under GTS Root R4). For a custom domain, Convika asks Cloudflare for the certificate without naming a certificate authority, and Cloudflare's certificate-authorities page lists Let's Encrypt, Google Trust Services, and SSL.com for those certificates. None of the certificates checked is on the emSign chain, and the steps above still apply to any server or software of your own (publish an HTML page).

Tell your users while you replace the certificate

If your certificate chains to emSign ECC Root CA - G3 and its replacement isn't in place by October 27, Chrome is expected to show your visitors a certificate error instead of your site. A notice at another address can tell them what happened and when to come back. Ask an AI chat to write it as one HTML page, then send its link by email or post it where your users look.

Convika turns that file into a link at a convika.page address, which presented a Let's Encrypt certificate in the check above: sign up free, drop the file on the upload screen, check the private preview, and publish. On the free plan the page is public, and search engines and Convika's gallery may list it.

Publish my notice page

Updates to this page

• October 23, 2026, 01:05 JST: first version. Sources read between 00:46 and 00:59 JST. Google's post, the incident page, Mozilla's NSS bug, eMudhra's status page, WordPress's 7.1 certificate list, and api.wordpress.org were read again at 01:04 JST, unchanged.
• October 23, 2026, 02:55 JST: Bun gets its own row: Bun 1.4.4, released October 22, updates its root certificates to NSS 3.131.1, and the incident page has listed it as patched since 01:04 JST; it was "pending" in the first version. Erlang certifi and Bottlerocket are still "pending" (02:49). Go's release date follows the Go release history (October 19). Chrome's counts are named as precertificates, the FAQ names the five eMudhra intermediates, the incident page's two No CT test hosts are added, and the composer/ca-bundle row gives the incident page's "pending" label.

This page changes on October 28 (JST), after a check of Chrome Stable once the root removal is due, and when WordPress ships a release with the new certificate list, when a Firefox release carries the NSS root removal, when eMudhra names a migration date, and when the incident page's pending rows change. The same week: PHP October 2026 security release: what to update, Node.js October 2026 security release: what to update, and Node.js 26 LTS on October 28: which version to run?. A Japanese page for site owners covers the same incident: eMudhra 中間証明書の問題：自分のサイトは対象？ (in Japanese).

Frequently asked questions

Is my website affected by the eMudhra compromise?

Only if its certificate chains to emSign ECC Root CA - G3. Chrome counted about 30,800 unexpired precertificates on that root on October 21, 99.9% issued by InCommon Intermediate CA - OVG3C or DVG3C. Check your issuer with openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer. Separately, software on your server that connects out over HTTPS, such as WordPress, Node.js, or Go programs, needs its own update.

Does Let's Encrypt chain to eMudhra?

No. Let's Encrypt issues certificates from intermediates under its own ISRG roots, per its chain-of-trust page, and Chrome's count of certificates on emSign ECC Root CA - G3 names only InCommon and eMudhra intermediates as their issuers.

What happens in Chrome on October 27?

Google expects Chrome to stop trusting emSign ECC Root CA - G3 on all devices that rely on the Chrome Root Store on Tuesday morning, October 27, 2026, PDT, and says "Some legitimate certificates chaining to this root will cease to function in Chrome as a result." As of 02:51 JST on October 23, the removal is scheduled, not done.

How do I check who issued my certificate?

Run openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer with your domain, or open the certificate viewer from the icon at the left of your browser's address bar. If the issuer is InCommon Intermediate CA - OVG3C or DVG3C, or EM EV TLS CA - G3A-1, EM OV TLS CA - G3A-1, emSign ECC SSL CA - G3, emSign ECC EV SSL CA - G3, or emSign TLS CA - G3, the certificate must be replaced.

Do I need to update Node.js for eMudhra?

Yes, if your Node.js programs connect to other servers over HTTPS. Node.js 22.23.4, 24.22.1, and 26.12.1, released October 21, 2026, carry the fix and reject chains containing the blocked keys. Node.js 20 and 25 reached end of life on April 30 and June 1, 2026, per the Node.js release schedule, and get no fix.

Is WordPress affected, and which version fixes it?

Yes, for WordPress's own outgoing requests, not for visitors. WordPress's development trunk dropped emSign ECC Root CA - G3 from its bundled certificate list on October 21, but as of 02:51 JST on October 23 no release carries it: the latest is 7.1.3, from October 6, whose branch still lists the root. Update when a release ships composer/ca-bundle 1.6.0.

Do I need to replace my certificate before October 27?

Only if it chains to emSign ECC Root CA - G3. For those certificates Google says operators "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store." Certificates from Let's Encrypt, Google Trust Services, and other issuers outside Chrome's count need nothing for this event.

Was the eMudhra compromise exploited?

Not against browsers that enforce Certificate Transparency, according to Google and the incident page; for other clients it is not known. Google: "no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients." The incident page: "We do not know if attackers exploited the flawed key generation to target these clients." Cloudflare says its review "has not identified active exploitation of this issue on Cloudflare services."

Is a certificate error in Chrome caused by this?

Only if the site's certificate chains to emSign ECC Root CA - G3, and the root's removal is expected from the morning of October 27 PDT. Open the certificate from the error page and read the issuer: if it isn't one of the intermediates in the table above, this event isn't the cause.

Sources

Times are October 23, 2026, in JST (UTC+9).

• Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates (00:46, 02:51)
• eMudhra Intermediate CA Compromise, the incident page by Dennis Jackson, with its roots and intermediates lists (00:46, 02:49)
• Mozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates, comments 18, 19, and 30 (00:46)
• Mozilla Bugzilla 2084101: Remove eMudhra emSign Root CA - G3 from NSS (00:46, 02:51)
• Chromium: root_store.textproto (00:46, 02:51)
• Firefox 158.0.1 release notes (00:46)
• Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know (00:46)
• Cloudflare Docs: Certificate authorities (00:46)
• eMudhra: Statement on Recent Certificate Security Incident and eMudhra to Exit global SSL/TLS Certificate Business (00:46, 00:48)
• Let's Encrypt: Chains of Trust (00:47)
• Node.js release schedule (00:59)
• Node.js: October 2026 security releases, v24.22.1 release notes, pull request #66871, and v24.22.1 src/node_root_certs.h (00:46, 00:47)
• CVE.org: CVE-2026-111943, golang-announce: Go 1.27.3 and Go 1.26.10 are released, and go.dev downloads, and the Go release history (00:46, 02:49)
• PyPI: certifi and Packagist: composer/ca-bundle, and composer/ca-bundle pull request #154 (00:46, 02:49)
• Bun v1.4.4 (02:49)
• WordPress commit 6591179472, the 7.1 branch ca-bundle.crt, the trunk ca-bundle.crt, and the 7.1 branch class-wp-http.php (00:46)
• WordPress.org version-check API (00:45, 02:51)
• Microsoft Support: Windows Secure Boot certificate expiration and CA updates (00:46)
• Let's Encrypt: 64-day certificate lifetimes (00:46)