Is Your SSL Certificate From eMudhra? How to Check and Replace It

Six eMudhra (emSign) TLS intermediates named EM DV, EM OV or EM EV TLS CA - G3B/G3C have compromised signing keys. A certificate issued through any of them needs replacement. Separately, Mozilla has announced removal of trust in emSign ECC Root CA - G3 and requested migration of all chains beneath that root. Some other eMudhra and Internet2/InCommon intermediates also chain to it; their own keys are not known to be compromised, but their chains may lose trust as root-store changes ship. Check the full trust path rather than relying on the six issuer names alone.

On 17 October 2026, Mozilla received a report about the private keys of eight eMudhra intermediate certificates. Mozilla's bug report describes the keys as tiny numbers (below 256) that were easy to recover. According to the community tracker, Chrome and Firefox blocked the intermediates that same day.

By the end of this guide you will know which chain your site, your origin server and your server-side tools (curl, Python, Node, Go) use, and how to replace the certificate safely if you are affected.

What actually happened with eMudhra?

A website certificate does not stand alone. Your certificate (the "leaf") is signed by an intermediate certificate, which is signed by a root certificate that browsers already trust. Think of a reference letter: you trust it because you trust the signer, and you trust the signer because someone you know vouches for them.

If an intermediate's signing key leaks, anyone can write fake letters. Mozilla's security blog says these keys "could allow attackers to issue fraudulent HTTPS certificates for websites they do not control."

What is confirmed, at the time of writing (25 October 2026):

• Eight eMudhra intermediates are affected: six for TLS (website certificates) and two for code signing, per Mozilla's Bugzilla entry.
• The six TLS intermediates are EM DV TLS CA - G3B, EM OV TLS CA - G3B, EM EV TLS CA - G3B, EM DV TLS CA - G3C, EM OV TLS CA - G3C and EM EV TLS CA - G3C.
• Each also exists as a cross-sign from Sectigo's AAA Certificate Services root. eMudhra revoked its versions on 18 October 2026, and Sectigo has revoked its cross-signs, though the tracker and the Bugzilla thread give different dates (19 and 24 October 2026).
• Chrome and Firefox blocked them on 17 October. Microsoft platforms followed on 20 October and Apple's frameworks on 22 October, according to the community tracker.
• Mozilla says NSS 3.131.1 removes emSign ECC Root CA - G3. That is separate from blocking the eight compromised intermediates: certificates chaining through other intermediates beneath that root may also need migration even though their intermediate keys were not reported compromised.
• eMudhra's press release of 21 October 2026 places the problem in its Global TLS business and says its India Digital Signature Certificate (DSC) and eSign services are unaffected.

What is not confirmed:

• A commenter in Mozilla Bugzilla reports more than 107,000 certificates or precertificates logged on 20–21 October and signed with the affected keys, many as proof-of-concept certificates naming google.com. This is public evidence of test issuance, not evidence that attackers used a forged certificate to intercept real traffic.
• eMudhra says it did not itself issue end-entity certificates from the eight affected intermediates. That narrower statement does not establish that nobody else signed certificates with the exposed keys; see the proof-of-concept report above.
• The confirmed key compromise concerns the eight intermediate signing keys, not an individual website private key. A site on one of the six TLS chains needs a replacement certificate. A site using another intermediate under emSign ECC Root CA - G3 faces a separate trust-removal migration, not a finding that its intermediate key leaked.

Heads up: this incident is still open and vendors are still shipping fixes. Re-check the sources at the end of this post on the day you act.

Before you start

• Access to your hosting panel (cPanel, Plesk, DirectAdmin) or SSH access to your server.
• A terminal with openssl. Linux and macOS include it; on Windows use WSL or Git Bash.
• A list of every hostname that serves HTTPS, such as www, shop, api and mail.
• Cloudflare dashboard access, if you use Cloudflare.
• A backup of the current certificate and private key. Step 4 shows how.
• About 20 minutes to check, plus 10 to 30 minutes to replace.
• Risk level: checking is read-only. Replacing a certificate can interrupt HTTPS if hostnames, bundle or key do not match; keep a private backup and verify the new chain before retiring the old files.

Find out which chain your site serves

Why this matters: your panel shows what is installed, but visitors get what the server actually sends. A proxy, load balancer or CDN in front can make them differ.

Step 1: Check the issuer in your browser

Open your site, click the icon to the left of the address, and follow the connection or security entry until you reach the certificate viewer. Labels change between browser versions, so look for the word "Certificate".

Read the "Issued By" field and the certificate above yours in the hierarchy. If you see one of the six G3B or G3C names, you are affected.

The catch: an updated browser may show a full-page warning for a blocked chain, so you may never reach its certificate viewer. Even a working page does not prove the origin or every client trust path is safe. Use the server and origin checks below and confirm the full chain with your CA or host.

Step 2: Ask the server directly with openssl

This command connects to your server, sends your domain name (SNI, which tells a shared server which site you want), and prints the subject (s:) and issuer (i:) of each certificate the server sends.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ +[0-9]+ s:|^ +i:'

Certificate 0 is your leaf, and its issuer line identifies its signing intermediate. If it names one of the six EM DV/OV/EV TLS CA - G3B/G3C intermediates, replace the certificate. A different issuer is not automatically clear: other intermediates, notably Internet2/InCommon, can chain to emSign ECC Root CA - G3, which Mozilla is removing from its root store. This command shows what the server sends, not every path a client may build. Ask your CA or host to identify the trust anchor if the path is unclear.

Quick tip: the OpenSSL manual says -showcerts lists only "certificates the server has sent" and that "It is not a verified chain." It shows what is served, not whether anyone trusts it.

Step 3: Ask openssl to verify the chain, and know its limit

This command makes the same connection but aborts with an error if verification against your machine's trust store fails.

openssl s_client -connect example.com:443 -servername example.com -verify_return_error -brief </dev/null

A healthy chain completes the handshake and reports successful verification. A broken one fails with a verify error.

Heads up: a pass does not prove you are safe. OpenSSL uses your system CA bundle and does not consult browser blocklists such as Mozilla's OneCRL. A chain using the Sectigo cross-sign can still pass on a machine that trusts AAA Certificate Services. The intermediate name from Step 2 is the real test.

Step 4: Back up the current certificate and key

Keep the old files until the new certificate is verified, so you have a one-minute way back if the install goes wrong. On a server you manage, this finds the files your web server uses.

sudo grep -RnE "ssl_certificate|SSLCertificate" /etc/nginx /etc/apache2 /etc/httpd 2>/dev/null

Then copy them into a private, dated folder with their permissions intact. Replace the example paths with the ones printed above.

sudo mkdir -p /root/cert-backup-2026-10-25
sudo cp -a /etc/ssl/example.com/fullchain.pem /etc/ssl/example.com/privkey.pem /root/cert-backup-2026-10-25/
sudo chmod 700 /root/cert-backup-2026-10-25

On cPanel, go to cPanel > Security > SSL/TLS. Under Certificates (CRT), edit the current certificate and save a copy. If you must export its Private Keys (KEY) entry, save it only in encrypted or access-restricted storage outside public_html and any other web-served folder. Never send a private key by email or chat, and securely remove retired copies after the replacement and rollback window.

For a full site backup routine, see how to back up a cPanel site with an offsite copy.

Check your hosting panel

In cPanel > Security > SSL/TLS, open the Certificates (CRT) section. The Certificates on Server table has an Issuer column, and Edit shows the decoded certificate with the full issuer name.

Manage SSL sites also has Certificate Details among its actions. cPanel's docs note this table only appears for domains with a dedicated IP address, so an empty table on shared hosting is normal.

cPanel > Security > SSL/TLS Status lists each domain's certificate status and AutoSSL errors, but the docs do not describe an issuer field. Use it to spot problems, and the SSL/TLS page to confirm the CA.

On a server without a panel, this prints the subject and issuer of every certificate in a chain file.

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/example.com/fullchain.pem | openssl pkcs7 -print_certs -noout

Check your server-side clients

Your server also makes outbound HTTPS calls: payment gateways, APIs, webhooks, backup uploads. Each tool has its own trust store, and each got its fix on a different day.

The community tracker published by Dennis Jackson publishes test hosts that use the compromised chain. A patched client should refuse them. The tests below use one of them.

Operating system CA bundle

On Debian or Ubuntu, this refreshes package lists and upgrades the CA package.

sudo apt update && sudo apt install --only-upgrade ca-certificates

On Fedora, RHEL, AlmaLinux or Rocky Linux, this does the same.

sudo dnf upgrade ca-certificates

At the time of writing, the tracker lists Debian, Ubuntu, Fedora, RHEL, Alpine, Arch and FreeBSD among patched systems, with some still pending, such as RHEL 7. A full system upgrade is better still, because libraries such as NSS carry their own fixes. For a wider check, see how to check a cPanel or Plesk VPS is patched in 10 minutes.

curl

This calls a tracker test host and prints curl's exit code.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/; echo "exit code: $?"

For the intended test chain, a certificate-verification failure is expected from an appropriately patched client. curl exit code 60 means certificate verification failed, but does not by itself identify this incident as the cause. Read the error and confirm the actual peer chain, proxy and CA configuration. Exit 0 means this transfer was accepted under that configuration; investigate before calling it safe. Update the supported CA package or application bundle through its documented process. DNS failures, timeouts and other transport errors are inconclusive; never add -k to force the test through.

Python

Python's ssl module usually uses the system trust store, while the requests library uses the certifi bundle. This shows both.

python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"
python3 -c "import certifi; print(certifi.__version__, certifi.where())"

The tracker lists certifi as fixed in 2026.10.19 and the interpreter in 3.15.1, 3.14.9 and 3.13.17. This upgrades certifi.

python3 -m pip install --upgrade certifi

This example prints TRUSTED if urllib accepts the HTTPS connection and response. A certificate-verification exception is relevant to this check; a DNS, timeout or HTTP error is not proof that the compromised chain was rejected. Confirm the served test chain and any proxy/custom trust settings. If the application uses requests, check that application and its actual CA bundle separately rather than treating urllib as a substitute.

python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Node.js

Node includes a bundled root list; the Node 24.22.1 release notes dated 21 October 2026 confirm an update to NSS 3.131.1. Use a supported patched release and inspect any custom CA or proxy configuration. The request below prints the HTTP status or the underlying error code. REQUEST_FAILED alone is not proof that certificate distrust worked: DNS, connection and timeout errors can also reject a fetch. Check that the failure specifically concerns certificate verification for the intended test chain.

node -v && node -e "fetch('https://dv-g3b-emudhra.we-have-a-problem.com/').then(r=>console.log('HTTP_RESPONSE',r.status)).catch(e=>console.log('REQUEST_FAILED',e.cause&&e.cause.code))"

Go

Go 1.27.3 and 1.26.10 were released on 19 October 2026. The golang-announce post says Go is "blocking trust in a small set of intermediate certificates due to specific security concerns around their operation" (CVE-2026-111943), and the tracker links this to eMudhra. Check with go version.

Why this matters: Go compiles the standard library into each binary, so upgrading Go does nothing for programs already built. Rebuild and redeploy your Go services with a fixed version.

Replace the certificate if you are affected

Step 5: Choose your replacement path

• Paid OV or EV certificate: contact eMudhra or your reseller. eMudhra's press release says it is "working directly with customers who may be affected" to provide replacements.
• Free DV certificate: issue one from Let's Encrypt through your panel (AutoSSL) or an ACME client such as Certbot. This works today without waiting for anyone.

Quick tip: if you did not choose OV or EV for a business reason, a free DV certificate is usually the fastest fix. You can move to a paid certificate later.

Step 6a: Let's Encrypt with cPanel AutoSSL

cPanel's docs say AutoSSL uses Let's Encrypt by default. On shared hosting, ask your host to run AutoSSL for your account and mention this incident. With root access, open Manage AutoSSL in WHM and click Run AutoSSL for All Users, or run this as root.

/usr/local/cpanel/bin/autossl_check --all

Heads up: AutoSSL does not normally replace certificates it did not issue. The cPanel docs describe an option to allow AutoSSL to replace invalid or expiring non-AutoSSL certificates, which changes that, and cPanel warns it could swap an EV or OV certificate for a DV one. Do not assume AutoSSL treats a distrusted chain as "invalid". If it skips your domain, install by hand (Step 6c) and check the Logs tab, which reads from /var/cpanel/logs/autossl.

Step 6b: Let's Encrypt with Certbot on Nginx or Apache

This requests a certificate and updates your Nginx config. Use --apache instead of --nginx for Apache.

sudo certbot --nginx -d example.com -d www.example.com

Certbot stores files in /etc/letsencrypt/live/example.com/: fullchain.pem holds your certificate plus intermediates, and privkey.pem is the key. Run sudo certbot certificates to see what it manages. HTTP-01 validation (Let's Encrypt fetching a file from your site) only works on port 80, so keep that port open.

Step 6c: Install a certificate by hand in cPanel

Go to cPanel > Security > SSL/TLS > Manage SSL sites. Under Install an SSL Website, select the domain, paste the certificate into Certificate (CRT), the key into Private Key (KEY) and the intermediates into Certificate Authority Bundle (CABUNDLE), then click Install Certificate. Make sure the bundle comes from the new CA, not the old eMudhra one.

Step 7: Test and reload the web server

This tests the Nginx config before reloading, so a typo does not take the site down.

sudo nginx -t && sudo systemctl reload nginx

For Apache, run sudo apachectl configtest and then reload the apache2 service (Debian, Ubuntu) or httpd (RHEL family).

If your site is behind Cloudflare

With the Cloudflare proxy on, visitors see Cloudflare's edge certificate, so Step 1 may look fine while your origin server still uses an eMudhra certificate. Cloudflare's docs say that in Full (strict) mode the origin certificate must be unexpired, match the hostname and be signed by a publicly trusted CA or Cloudflare's Origin CA, or visitors may see a 526 error.

This runs the Step 2 check against your origin IP, bypassing Cloudflare. Replace 192.0.2.10 with your server's address.

openssl s_client -connect 192.0.2.10:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ +[0-9]+ s:|^ +i:'

If the origin shows one of the six G3B/G3C issuer names, replace its certificate. Also ask the origin certificate provider whether any other chain terminates at emSign ECC Root CA - G3; if so, arrange a replacement chain even if the six names are absent. Lets Encrypt or Cloudflare Origin CA can be appropriate for an origin, depending on your Cloudflare mode and host setup.

Your rollback plan

Restoring the old certificate brings back a chain browsers already reject, so it fixes nothing for visitors. Its job is to return you to a known state if the new install breaks something else, such as a missing hostname or a key mismatch.

• Keep the Step 4 backup until the new certificate has passed every check below for at least a day.
• On a server, roll back by pointing the config at the backup files, testing and reloading.
• On cPanel, paste the saved certificate, key and bundle back into Install an SSL Website.
• Once you are happy, delete the old private key. A retired key is still a key.

Made-up example: Priya replaces her shop certificate and confirms it no longer serves an affected chain. She separately checks outbound clients used by the stock-sync service, rebuilds any affected Go binaries with a supported patched release, and verifies both their trust behavior and the real stock-sync operation. A successful homepage is not a test of outbound clients.

How to check it worked

• Run Step 2 again: the served chain should no longer show a compromised G3B/G3C intermediate. Confirm with the issuing CA or host that the full trust path does not terminate at the distrusted emSign ECC Root CA - G3, including for alternate chains the server may offer.
• Run Step 3. Verification should succeed.
• Open the site in a private window and view the certificate. "Issued By" should show the new CA with a new expiry date.
• Repeat for every hostname, including www, subdomains, mail and API hosts.
• Behind Cloudflare, test the origin IP and load the site with Full (strict) on.
• Rerun the curl, Python and Node tests. The tracker host must still be refused, which proves your clients are patched too.

Troubleshooting

Visitors still get a certificate warning after the change

Likely cause: the server still sends the old chain because it was not reloaded, or another virtual host points at the old file. Fix: run Step 2, find the old path with the Step 4 grep, update it and reload.

Nginx will not start: "key values mismatch"

The Nginx docs show SSL_CTX_use_PrivateKey_file(...) failed (SSL: error:05800074:x509 certificate routines::key values mismatch) when the intermediates come before your certificate in the file, or the key belongs to another certificate. Fix: put your certificate first, then the intermediates, with its own key.

Let's Encrypt refuses to issue because of CAA

Likely cause: a CAA record (a DNS rule naming which CAs may issue for your domain) allows only eMudhra. Check with dig +short CAA example.com, then add 0 issue "letsencrypt.org". See CAA records explained.

Certbot fails HTTP-01 validation

Likely cause: port 80 is closed, or a redirect sends the check elsewhere. Let's Encrypt validates HTTP-01 only on port 80 and follows redirects only to ports 80 or 443. Fix: open port 80, or use DNS-01 validation.

You hit a Let's Encrypt rate limit

Let's Encrypt limits how many certificates and failed validations you can have in a period. Fix: stop retrying, find the cause, and test with certbot renew --dry-run, which uses the staging server.

The site is fixed, but a script or API call still fails

Likely cause: a client pins the old intermediate, or an old binary carries an old trust store. Fix: update the pin, update the CA bundle, rebuild Go services and upgrade Node or certifi. If a mobile app pins certificates, ask its developer, since that may need an app release.

Your origin is fixed, but visitors still see the old certificate

Likely cause: a CDN or load balancer holds its own copy. Fix: upload the new certificate there too, or ask your host which layer handles HTTPS.

The one message worth forwarding

"Hi, the signing keys of six eMudhra TLS intermediates (EM DV, OV and EV TLS CA - G3B/G3C) were compromised and blocked in October 2026 (Mozilla bug 2083449). Mozilla is also removing trust in emSign ECC Root CA - G3, so other chains beneath that root may need migration without their keys being compromised. Could you check the full trust path for all our HTTPS endpoints, origin servers and load balancers, including any Internet2/InCommon chain? If a chain is compromised or being distrusted, please back up its current certificate and key privately, install a replacement, and verify what each server serves. Please update outbound HTTPS clients and rebuild affected Go services as needed. Thanks."

Check the intermediate and the full trust path your site uses; the six compromised issuer names are an urgent trigger, but not the entire G3-root migration scope.