Certificate Trust Store Audit Before October 27: NC Guide

If the browsers in your office updated themselves last week, good. The exposure that is left sits on the servers and devices in the plant that nobody browses from, and one date matters: Tuesday, October 27.

TL;DR: On October 17, 2026, a researcher reported that eight eMudhra intermediate certificate authorities had weak private keys. Chrome and Firefox blocked them within hours, and eMudhra revoked all eight on October 18. Software that keeps its own trusted-certificate list, or skips revocation checks, may still accept a forged certificate: Java, Python and Node.js apps, containers, older servers and appliances. Separately, Chrome expects to remove the emSign ECC Root CA - G3 root from its root store on Tuesday morning, October 27, 2026 PDT, and Google says some legitimate sites still using certificates from that root will stop working in Chrome.

What happened with the eMudhra certificates?

Eight intermediates had private keys anyone could work out, and browser makers moved within hours. Google's October 20 Chrome Root Program post says the keys "were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs."

eMudhra's own statement, updated October 22, says the researcher reported that the keys "were cryptographically weak," that "We revoked all eight intermediates the following day," and that "No certificates had been issued from any of them, our infrastructure was not compromised, and no data was breached." It says the intermediates were created on April 30, 2025. On misuse, eMudhra says: "We are not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed."

On October 22, eMudhra announced that its Board "has decided to voluntarily withdraw from the global SSL/TLS certificate business," and said its G1 RSA roots "will continue to serve customers until this transition is complete."

Not sure what in your building would still trust these certificates? Our cybersecurity team can run the checks below with you. Call (336) 886-3282 or tell us what you run.

If Chrome and Firefox are fixed, what is still exposed?

Everything that checks certificates without a browser's fast-revocation channel. Google says no TLS certificates from these intermediates were logged to Certificate Transparency before its block, so "no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients." That reassurance covers Chrome and similar clients, and only for the time before the block. It does not cover a Java service calling your carrier's API. Our reading: server-side software like that generally does not enforce Certificate Transparency, and Google's point does not mean no forged certificates exist. Anyone who holds the keys can sign new ones, which is why the blocks and trust-store updates matter.

Other people have since worked the keys out too. In the Mozilla incident record, Mozilla wrote on October 20 that "multiple individuals have independently recovered the private keys for these intermediates."

Cloudflare's October 20 write-up puts it plainly: "Updating the SDK alone may not change the underlying policy."

For a plant in High Point, Greensboro or Charlotte, that usually means:

• the server that moves orders between your ERP and a customer portal or EDI service;
• scripts and integrations written in Python, Java, .NET or Node.js;
• Docker containers built from an older base image;
• backup software, monitoring agents and the RMM agent;
• VPN appliances, firewalls, label printers, HMIs and other embedded devices that only update with firmware;
• older Windows and Linux servers that have no path to the internet for update lists.

Key takeaway: Chrome updating itself tells you nothing about the server that posts your orders to a customer portal at 2 a.m. Test that server on its own.

Why does removing the emSign root not finish the job?

Because each TLS key also chains through a second root, run by Sectigo. This section is for whoever runs your servers. Apple's support note says each of the six TLS intermediates has two certificates: one that "chains to emSign ECC Root CA - G3" and "A certificate cross-signed by Sectigo, which chains to AAA Certificate Services." It warns that removing the emSign root "doesn't block the six certificates that Sectigo cross-signed."

Sectigo said in the Mozilla record that its AAA Certificate Services root "remains trusted within Microsoft and Apple root programs," and on October 19 that it "has completed the revocation of the affected cross-signed CA Certificates." Revocation only helps software that checks it. A hand-patched trust store has to handle both roots, so vendor updates that block the specific intermediates are the safer route.

What exactly changes on October 27, 2026?

Google says the emSign ECC Root CA - G3 removal "is expected to be released for all devices relying on the Chrome Root Store Tuesday morning, October 27, 2026 PDT." It adds that "Some legitimate certificates chaining to this root will cease to function in Chrome," and that site operators "must immediately acquire and install a new TLS certificate from another PKI hierarchy."

So Tuesday can break things that were working fine: a supplier portal your buyers open in Chrome, say, if it still uses a certificate from that root. Mozilla is removing the same root from its NSS trust store in NSS 3.131.1, and Apple says it began blocking the root on October 23.

To see what a site you depend on chains to, open it in a browser and view the certificate's hierarchy, or run this from any machine with OpenSSL (Linux, a Mac, or Git Bash on Windows) and read the issuer lines:

openssl s_client -connect portal.example.com:443 -servername portal.example.com -showcerts </dev/null | grep -E "s:|i:"

An issuer line naming emSign ECC Root CA - G3, or emSign Root TLS CA - G3 (which Apple says chains to it), means that site needs a new certificate before Tuesday. Servers often leave the root off the chain they send, so for any other emSign or eMudhra name, ask the site's owner which root it chains to.

How do you find what in the plant still trusts the bad certificates?

Test each machine the way its software connects. The public test site that Cloudflare points readers to serves certificates from the compromised intermediates. Its instructions say to run:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

and that "A certificate error means the client does not trust the compromised intermediates." The page loading without an error means that client still trusts them. On a Windows server, run curl.exe from PowerShell; on Windows Server 2016 and older, which have no curl.exe, our suggestion is [Net.ServicePointManager]::SecurityProtocol = 'Tls12'; Invoke-WebRequest https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ -UseBasicParsing, where an error about a trust relationship is the result you want.

Cloudflare's caution applies: "A successful browser test does not prove that a background service is protected. Neither does a curl test if the application uses a different verifier." For Java, OpenJDK publishes a checker program, CheckCerts.java, for JDK 8 and later.

Our view: the machines that miss fixes like this are the ones nobody logs into, usually the ERP integration box under someone's desk, the historian on the plant network and the label-print server. Start your list there, not at the front office.

How do you update each trust store?

Patch first, then restart whatever reads the store. Cloudflare paired its trust-store updates "with reloads, restarts, and image deployments needed to activate them." OpenJDK likewise says to restart any live instances of the runtime.

1. Windows. Microsoft's certificate trust documentation says Windows downloads its trusted and untrusted lists "from the Internet via an automatic mechanism," and that this "can be disabled if necessary, although isn't recommended." Check that it is on; for isolated plant servers, the same page describes a Group Policy setting that points them at an internal server instead. We found no Microsoft statement that these certificates are blocked, so test each server.
2. Linux. Install your distribution's updated ca-certificates package. Ubuntu's tracking bug lists 20260816ubuntu0.22.04.1 and 20260816ubuntu0.24.04.1, and Red Hat rates its RHEL 9 ca-certificates update Critical.
3. Java. OpenJDK says to act immediately on a standalone runtime, even one updated in the past few days, by installing a build whose release note names JDK-8395690. If none exists yet, it gives keytool commands to delete four root aliases, including emSign Root CA - G1 and AAA Certificate Services, and says to back up the runtime's keystore first and restart any live instances afterward. Our caution: those roots also anchor certificates that were never compromised, so a Java app may stop reaching some legitimate sites; retest your integrations afterward. On Debian and Ubuntu, OpenJDK says package updates alone are "not sufficient" and gives a workaround: rm -f /etc/ssl/certs/java/cacerts then update-ca-certificates --fresh, as root.
4. Python, Node.js and Go. Update Python's certifi package to 2026.10.19 or later (the PyPI listing shows 2026.10.23 as current). Node.js 26.12.1, 24.22.1 and 22.23.4 update their bundled root certificates to NSS 3.131.1. Go 1.27.3 and 1.26.10 block "a small set of intermediate certificates." Update, rebuild, restart.
5. Containers. Rebuild from an updated base image and redeploy.

Cloudflare warns that after patching you may see certificate errors, and "It's important to not resolve these errors by disabling verification." Veeam expects errors where a service's certificate chains to emSign ECC Root CA - G3 or AAA Certificate Services. That is a vendor certificate to replace, not a setting to loosen.

Want a second set of hands on the server list? Our managed IT and network engineers can work through it with you. (336) 886-3282.

What does the code-signing half mean for software you run?

Two of the eight intermediates were for signing software, not websites. The Mozilla record says "The other two certificates are for codesigning and trusted by Microsoft," while Apple says they "issue code signing certificates, which Apple's frameworks don't trust." In the same record, eMudhra wrote that "The Code Signing issuers were not put into production also did not issue any certificates."

Our reading: if eMudhra's account is right, a program or script whose signature chains to EM OV CS CA - G3B or EM OV CS CA - G3C was not signed by an eMudhra customer, so treat it as suspect. Google's Certificate Transparency reassurance is about TLS certificates; it says nothing about code signing.

To check a Windows file, run (Get-AuthenticodeSignature .\file.exe).SignerCertificate.Issuer in PowerShell. A result naming EM OV CS CA - G3B or G3C is the match. To sweep a folder of tools and installers, run Get-ChildItem C:\Tools -Recurse -Include *.exe,*.dll,*.msi,*.ps1 -ErrorAction SilentlyContinue | Get-AuthenticodeSignature | Where-Object { $_.SignerCertificate.Issuer -match 'EM OV CS CA - G3[BC]' }, changing the path to suit. For Java, OpenJDK gives jarsigner -verify -revcheck -strict to verify a signed JAR and check revocation, on JDK 17 and later.

If you find a match, our advice is to treat the machine as a possible incident: disconnect it from the network but leave it powered on, do not delete, move or run the file, and call your cyber insurer and incident responder. Have your responder capture memory and image the disk before anyone restarts, cleans or reimages it.

What should you ask your software and hardware vendors this week?

Ask in writing. Veeam's October 21 support statement is a useful model: its own appliances got a blocklist update through Veeam Updater, while on other servers "the fix comes from the operating system vendor."

1. Does your product use the operating system's trust store, or its own (a bundled Java, Python, Node.js or Electron runtime, or firmware)?
2. If its own, which version blocks the eight intermediates and their Sectigo cross-signed copies, and when did it ship?
3. Does any certificate you present to us, on a portal, API or update server, chain to emSign ECC Root CA - G3? When will it be replaced?
4. Was anything you ship to us signed through an eMudhra code-signing certificate?
5. After we update, what has to be restarted or redeployed?

"We use standard certificates" answers none of these. If that is the reply, ask for someone on the vendor's engineering team.

What should a Piedmont Triad plant do on Monday, October 26?

Morning: check the chain on each outside site you depend on (customer portals, EDI, carrier and bank connections, anything your ERP calls) and get anything on emSign ECC Root CA - G3 replaced before Tuesday. Afternoon: run the curl test on the ERP integration server and the other quiet machines in the table, and email the vendor questions. Write down what each machine trusts; you will want that list the next time a certificate authority fails, and our manufacturing IT support team can help you build it.

Preferred Data Corporation has been in business since 1987. We are headquartered in High Point, North Carolina, work on site within 200 miles, and support clients remotely across the United States and around the world. Call (336) 886-3282, email [email protected], or visit us at 1208 Eastchester Drive, Suite 131, High Point, NC 27265.

Frequently Asked Questions

Our browsers updated themselves. Are we done?

No. Chrome, Firefox and Safari are covered, per Google, Mozilla and Apple. Servers, Java and Python apps, containers and appliances with their own certificate lists may still trust the weak intermediates until each one is updated and restarted.

Will anything stop working on October 27?

Possibly. Google expects to remove emSign ECC Root CA - G3 from the Chrome Root Store on Tuesday morning, October 27, 2026 PDT. Google says some legitimate certificates chaining to that root will stop working in Chrome, so any site still using one needs a new certificate from its owner.

Was anyone actually attacked with these keys?

eMudhra says it is not aware of any evidence the weak keys were recovered or exploited before disclosure. Google says that because no TLS certificates from these intermediates were logged to Certificate Transparency before its blocking action, none could have been used against clients that enforce Certificate Transparency, such as Chrome. That covers the time before the block, and only those clients. Mozilla says several people have since recovered the keys independently, so new forged certificates are possible; software that does not enforce Certificate Transparency and has not been updated is still exposed.

Do our Windows servers fix this automatically?

We could not find a Microsoft statement saying it has blocked these certificates. Microsoft does say Windows downloads its certificate trust lists automatically by default, and that this can be turned off. Run the curl.exe test on each server, isolated plant servers first.

Is eMudhra leaving the TLS certificate business?

eMudhra announced on October 22, 2026 that it will withdraw from the global SSL/TLS certificate business. It says its G1 RSA roots will keep serving customers through the transition, and that its digital signature and eSign services are not affected.

Related Resources

• TLS Certificates Now 200 Days: Guide From High Point, NC
• Windows Update Cutoff May 2027: NC Plant PC Check Plan
• Jscrambler npm Supply Chain Attack: NC SMB Build Pipeline Defense