eMudhra Exits the TLS Certificate Business: What Customers Do Now

eMudhra announced on 22 October 2026 that it will leave the global SSL/TLS certificate business after the weak intermediate key incident. If you hold an emSign certificate, find every copy, replace anything chaining to the G3 ECC root before Chrome's 27 October root removal, then plan the G1 RSA certificates off a hierarchy that is now winding down.

Our eMudhra CA key compromise explainer covers what went wrong: eight intermediate keys small enough to compute, the 16 certificates involved, browser blocks and trust store fixes for clients. This post does not repeat that. It picks up where the exit begins, for the people who bought certificates from eMudhra, run services behind them, or depend on emSign roots in software they ship.

What eMudhra announced

According to eMudhra's press release dated 22 October 2026 from Bengaluru, its board decided to "voluntarily withdraw from the global SSL/TLS certificate business." The release is signed off by Chairman V. Srinivasan and sets out the terms as follows.

The release does not give a wind down date, a transition timeline, the names of the partners who will issue replacements, or a date for the root cause report. Every planning decision below assumes those gaps stay open for a while.

eMudhra also restates its own account of the incident in the release. It says it revoked the affected CAs within 14 hours of discovery, that no end-entity certificates were issued from those CAs, that its infrastructure was not compromised, and that no data was breached. These are eMudhra's claims. The root programs have asked follow-up questions that are still unanswered in public, and the root cause report has not been published. Google's separate finding, that no TLS certificate chaining to the affected intermediates was logged in Certificate Transparency (CT) before its block, is consistent with eMudhra's statement on end-entity issuance, but it is a statement about CT, not a full audit.

Reuters, via Yahoo Finance, reported that eMudhra's shares fell 40% in the two days after disclosure and quoted the company's view that the scrutiny was out of proportion to the size of the business line. The Next Web reported the same exit terms and the same list of continuing products.

Why the exit changes your plan

Before 22 October, a customer with an emSign certificate under the G3 ECC root had a clear path: eMudhra told Mozilla it would move subscribers to intermediates under its G1 RSA root, which it described on the Mozilla bug as the only alternative available. That was a migration inside one CA.

After 22 October, that same G1 RSA hierarchy is the one being wound down. The G1 roots keep working until the transition is complete, according to the release, but there is no stated end date. So a certificate you move from G3 to G1 this week may need to move again later, this time to a different CA entirely.

That gives you three separate problems, on three separate clocks:

1. Certificates chaining to emSign ECC Root CA - G3. Chrome expects to remove that root from the Chrome Root Store on the morning of Tuesday 27 October 2026, Pacific time. Mozilla already removed it in NSS 3.131.1. These need replacing now.
2. Certificates chaining to the G1 RSA roots. These are not distrusted today. Mozilla wrote on its bug on 20 October that it is not removing trust in emSign Root CA - G1 "at this time." But the issuer is leaving the market, so these need a planned move before the hierarchy stops being maintained.
3. Everything that trusts emSign roots. Applications that pin emSign keys, private trust configurations that include emSign roots, and mutual TLS setups that accept emSign client certificates all need a decision, independent of where your own server certificates come from.

Treat the first as an incident, the second as a project, and the third as cleanup.

Timeline

All times UTC unless marked. Times come from the sources named in each row.

The 14 hour figure in the press release depends on where you start the clock. The parent post's timeline, drawn from Mozilla Bugzilla and CERT-In, puts eMudhra's revocations at 09:24 to 09:38 UTC on 18 October. Measured from Mozilla's receipt of the report at 20:06, that is about 13 hours 18 minutes. Measured from Chrome's receipt at 18:05, about 15 hours 19 minutes. Neither is wrong; they measure from different moments.

Technical details

This section lists the identifiers you need to decide which of your certificates are urgent. For the eight weak intermediates and their 16 certificates (serials, certificate hashes, SPKI hashes and the published private key values), use the tables in our explainer. They are not repeated here.

The root being removed now

From the tracking site's roots.json, read on 22 October:

The "Included" status for emSign ECC Root CA - G3 in that file reflects the root store data the site uses, not the shipped removals. Mozilla has already dropped it from NSS 3.131.1, and Chrome's removal is scheduled for 27 October. Microsoft and Apple have blocked the eight intermediates; the root's status in their stores after this week is not stated in the sources we read.

The G1 RSA hierarchy that continues for now

eMudhra's release refers to its G1 RSA roots without naming them. crt.sh shows these RSA certificates in the G1 family. Values below come from the crt.sh certificate pages, read on 22 October.

Some practical notes on those rows:

• The emSign Root CA - G1 subject is C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign Root CA - G1, and its Subject Key Identifier is FB:EF:0D:86:9E:B0:E3:DD:A9:B9:F1:21:17:7F:3E:FC:F0:77:2B:1A, according to crt.sh.
• The self signed emSign Root TLS CA - G1 and its cross certificate share one SPKI hash. A rule that matches on the public key catches both, the same way Chrome's CRLSet matched the weak G3 intermediates.
• The cross certificate carries CA:TRUE, pathlen:1 (critical). That means emSign Root TLS CA - G1 can sign intermediates that issue end-entity certificates, but no deeper.
• crt.sh also lists, under emSign Root CA - G1, cross certificates for emSign Root Client Auth CA - G1 (crt.sh 14658191771) and emSign Root SMIME CA - G1 (crt.sh 14658191775), both valid 11 July 2024 to 9 July 2039. Those cover client authentication and email, not TLS server certificates, and the exit announcement does not address them.
• On 22 October, crt.sh showed all three G1 certificates above as not revoked by their CA's CRL, by Google's CRLSet, by Microsoft's disallowedcert.stl and by Mozilla's OneCRL. Its WebTrust audit listing shows a period of 1 June 2025 to 31 May 2026, by BDO International.
• crt.sh also lists emSign Root CA - C1 (crt.sh 713593222), issued to eMudhra Inc in the United States and valid 18 February 2018 to 18 February 2043. Its certificate page did not load when we tried, so we do not list its fingerprint or key type here.

Open questions about the G1 hierarchy itself

The exit does not close the root programs' questions, and some touch G1 directly.

• On the Mozilla bug, a participant credited as Zihao Wang reported that CRL number 11 for emSign Root TLS CA - G1, dated 14 October 2026, was signed with a key matching an OCSP certificate named EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4, rather than with the root key. The reporter called that reassuring, because it looked like a wrong key error rather than another weak key.
• The researcher credited as Wayne disagreed in comment 36. He wrote that several CRLs detected on 14 October were signed with OCSP certificates generated that same day and then swapped on the next CRL without an incident report, and that the problem may predate his monitoring.
• Chrome's question 12 asks which key signed that CRL and whether duplicate keys exist for other roots. Chrome's question 2 asks whether subscribers are moving to G1, to another CA owner's hierarchy, or both. On 22 October the bug showed no answer to either.

None of this means G1 is distrusted. It means the G1 hierarchy is under active questioning while its operator plans to leave TLS, which is a reason not to treat it as a long term home.

How many certificates are involved

Two things follow. First, most of the G3 certificates were issued under a separately branded service on eMudhra's hierarchy, not under an eMudhra branded intermediate. If your certificate came from a reseller or a service with its own brand, check the chain, not the invoice. Second, nearly all were issued through ACME, which is good news: an ACME client can usually be pointed at a different CA with a configuration change.

The CVE you will see in scanners

CVE-2026-111943 is not a CVE "for eMudhra." It was assigned by the Go CNA for the Go standard library's crypto/x509 package. Per the CVE record:

The record notes that on most platforms Go uses the system root certificates, and the fix adds a denylist so Verify returns an error on the known untrusted intermediates. Scanners that match this CVE will flag Go binaries built with older toolchains. That is useful for the client side of the incident, but it says nothing about which server certificates you hold. That is the gap this post is about.

Who needs to do what

Step by step: find, replace, verify

1. Find every eMudhra certificate you serve

Start outside in. CT logs list every publicly trusted certificate issued for your domains, regardless of who bought it or where it is installed.

# All certificates logged for your domain and its subdomains (crt.sh JSON output)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | [.not_after, .issuer_name, .common_name] | @tsv' \
  | grep -i -E "emsign|emudhra" | sort -u

Then check what each endpoint actually presents. A certificate in CT may never have been deployed, and an endpoint may still serve one you forgot.

# Print issuer and expiry of the leaf, and the subject/issuer of every chain element
host=api.example.com
openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
  | grep -E "^ *[0-9]+ s:| i:"
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -fingerprint -sha256

For a list of hosts, loop and keep the output as evidence:

while read -r h; do
  printf '%s\t' "$h"
  echo | timeout 10 openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null \
    | openssl x509 -noout -issuer 2>/dev/null || echo "no-tls"
done < hosts.txt | tee tls-issuers.tsv
grep -i -E "emsign|emudhra" tls-issuers.tsv

Do not stop at port 443 on public hostnames. Check internal listeners, SMTP with STARTTLS (openssl s_client -starttls smtp -connect mail.example.com:25), database proxies, and any service with a public certificate on a non standard port.

2. Find the copies on disk

The same certificate is often installed in five places. Search for PEM files and keystores whose issuer names emSign.

# PEM and CRT files on a host
sudo find / -xdev \( -name "*.pem" -o -name "*.crt" -o -name "*.cer" \) -size -64k 2>/dev/null \
  | while read -r f; do
      openssl x509 -in "$f" -noout -issuer 2>/dev/null | grep -qi emsign && echo "$f"
    done

# Java keystores (repeat per keystore and per JDK)
keytool -list -v -keystore server.jks -storepass "$STOREPASS" | grep -i -A2 "emsign"

# Windows (PowerShell): machine certificates issued under emSign
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -match "emSign" } |
  Select-Object Subject, Issuer, NotAfter, Thumbprint

On Kubernetes, check TLS secrets and cert-manager resources:

kubectl get secrets -A --field-selector type=kubernetes.io/tls -o json \
  | jq -r '.items[] | [.metadata.namespace, .metadata.name, .data["tls.crt"]] | @tsv' \
  | while IFS=$'\t' read -r ns name crt; do
      echo "$crt" | base64 -d | openssl x509 -noout -issuer 2>/dev/null \
        | grep -qi emsign && echo "$ns/$name"
    done
kubectl get clusterissuers,issuers -A -o wide

Load balancers, CDNs and managed certificate stores hold their own copies. Export the certificate list from each provider's console or CLI and grep the issuer field the same way.

3. Sort by hierarchy

For each certificate you found, work out which root it chains to. The chain output from openssl s_client -showcerts shows each issuer. Match the top of the chain against the Technical details tables:

• Ends at, or chains through, emSign ECC Root CA - G3: urgent, replace before 27 October.
• Ends at emSign Root CA - G1 or emSign Root TLS CA - G1: planned move.
• Anything else from eMudhra (for example, an S/MIME or client authentication certificate): not part of the TLS exit as announced, but ask your account team.

If you have the full chain in a file, you can confirm by fingerprint:

# Split a chain file into one certificate per file, then fingerprint each
csplit -s -z -f cert- chain.pem '/-----BEGIN CERTIFICATE-----/' '{*}'
for c in cert-*; do
  openssl x509 -in "$c" -noout -subject -fingerprint -sha256
done

4. Choose where the replacement comes from

eMudhra says it will contact customers and replace certificates free of cost through partners. It has not named the partners or the roots in public. On 22 October a participant on the Mozilla bug asked exactly those questions, plus how many certificates and on what timeline, and no answer was recorded.

Your options are:

• Accept eMudhra's partner replacement. Ask in writing which CA operator will issue the certificate, which root it chains to, the validity period, whether ACME is supported and with what directory URL, and who you contact for revocation and support after the transition.
• Buy or obtain your own. Google's advice for G3 certificates is to get one "from another PKI hierarchy included in the Chrome Root Store." Check that the issuer you pick is also included in the Mozilla, Apple and Microsoft stores if your users span those platforms.
• Do both. Take the free replacement as a stopgap for the 27 October deadline, then move to your chosen long term issuer on your own schedule.

Whatever you choose, do not move a G3 certificate to G1 as a final step. The G1 roots continue only until the transition is complete.

5. Switch ACME without a gap

Since eMudhra says about 97% of the G3 certificates came through ACME, most migrations are an ACME configuration change. The pattern is the same for every client: register an account with the new CA's directory, issue in parallel, deploy, then retire the old account.

With certbot:

# Register and issue against a new ACME directory (values from your new CA)
sudo certbot certonly --server "https://acme.newca.example/directory" \
  --eab-kid "$EAB_KID" --eab-hmac-key "$EAB_HMAC" \
  -d example.com -d www.example.com --cert-name example.com-newca

# Inspect what renewal config each lineage uses
sudo grep -H "^server" /etc/letsencrypt/renewal/*.conf

With acme.sh:

acme.sh --register-account --server "https://acme.newca.example/directory" \
  --eab-kid "$EAB_KID" --eab-hmac-key "$EAB_HMAC"
acme.sh --issue --server "https://acme.newca.example/directory" -d example.com -w /var/www/html

With cert-manager, create a second Issuer or ClusterIssuer pointing at the new directory, change the issuerRef on each Certificate, and let it reissue:

kubectl get certificates -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,ISSUER:.spec.issuerRef.name
kubectl -n prod patch certificate api-tls --type merge -p '{"spec":{"issuerRef":{"name":"newca-issuer","kind":"ClusterIssuer"}}}'
kubectl -n prod describe certificate api-tls | tail -20

The directory URL and the external account binding values (--eab-kid, --eab-hmac-key) come from your new CA. They are placeholders here.

Chrome's question 5 to eMudhra asks what mechanism will trigger ACME renewals outside normal renewal windows. The standard tool for that is ACME Renewal Information, RFC 9773, published in June 2025. A CA that supports it publishes a renewalInfo URL in its ACME directory with a suggestedWindow for each certificate. The RFC explicitly allows a CA to move that window earlier, for example ahead of a mass revocation. A client that supports ARI fetches the window after issuance, picks a random time inside it, and renews immediately if that time has passed. If your client does not support ARI, assume nothing will renew early on its own and force it.

6. Update CAA records

CAA, defined in RFC 8659, is a DNS record that names the CAs allowed to issue for your domain. CAs must check it before issuing. If your zone authorises only eMudhra, your new CA will refuse to issue.

dig +short CAA example.com
dig +short CAA www.example.com

Add an issue record for your new CA, using the exact issuer domain value from that CA's documentation, before you request certificates. Keep the old value only as long as you still need eMudhra or its partner to issue. Add issuewild if you use wildcards, and an iodef contact if you want violation reports. RFC 8659 is clear that CAA governs issuance only: it does not affect certificates already issued, and relying parties must not use it for validation. It is a guard on future issuance, not a fix for anything already out there.

7. Handle pins before you switch

If a mobile app, desktop client, SDK or device pins an emSign intermediate or root public key, a certificate from another CA will fail the pin and break that client. Order matters:

1. Find the pins: search your app code and configuration for SPKI hashes and for emSign certificate files bundled as assets.
2. Ship an app release that adds the new CA's SPKI hashes as backup pins, alongside the old ones.
3. Wait for enough of your user base to update.
4. Switch the server certificate.
5. Ship a later release that removes the emSign pins.

The G1 SPKI hashes in the Technical details table are the values to search for if you pinned a G1 root. If you pinned an intermediate, fingerprint the intermediate in your current chain with:

openssl x509 -in intermediate.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | base64

That base64 form is what most pinning libraries use.

8. Deploy, verify, revoke

Deploy the new certificate to every location you found in steps 1 and 2. Then verify from the outside:

echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate
curl -sv https://api.example.com/ 2>&1 | grep -E "issuer:|expire date:|SSL certificate verify"

Check that the full chain is served (the -showcerts output should include the intermediate) and that clients on each platform you support connect without warnings.

Once nothing serves the old certificate, ask the issuer to revoke it. eMudhra says its revocation and status services will run until every issued certificate has expired or been replaced, so revocation should remain available during the transition. Revoking keeps an unused certificate from being misused if its private key leaks later.

9. Watch CT afterwards

Set up monitoring that alerts on any new certificate for your domains. After the migration, you should see only your new CA. Anything from eMudhra or an unknown issuer after your cutover deserves a question. CT shows mis-issuance after it happens rather than preventing it, but it is the check that tells you your inventory is still right next month.

Relying parties: what to trust after the exit

If you configure trust rather than buy certificates, the exit raises one decision beyond the explainer's checklist: whether to keep emSign G1 roots in private trust configurations you control.

Public trust stores are the root programs' call. Mozilla has said it is not removing G1 at this time; Chrome is asking eMudhra where subscribers will go. Do not hand edit OS or browser stores ahead of them. Doing so cuts off legitimate sites that still use G1 certificates.

Private trust is your call. Consider:

• mTLS trust bundles. If a service accepts client certificates from public CAs, it should not. Replace the public bundle with your own CA. If you specifically accept emSign client certificates from partners, agree a replacement issuer and date with them.
• Pinned trust in your own clients. If you built a client that trusts only emSign Root CA - G1 because one partner used it, that client breaks when the partner moves. Ask the partner for their plan.
• Allow lists and inspection proxies. Rules that allow traffic signed by specific roots need updating as partners move off emSign.

For the G3 removal itself, the explainer's runtime table (certifi 2026.10.19, Go 1.27.3 and 1.26.10, NSS 3.131.1, the JDK builds and distribution packages) still applies, and container images still need rebuilding. Our post on container image supply chain incidents covers why a host update never reaches a running image. Cycle's write up makes the same point and lists Python certifi 2026.10.19, Go 1.27.3 and 1.26.10, and Rust webpki-roots 1.0.10 as fixed versions.

The products that continue

eMudhra says its digital signature certificates, eSign, emSigner, emCA, CertiNext, SecurePass and emAS continue unchanged and run separately from the TLS infrastructure. Our explainer records CERT-In's statement that the domestic DSC and eSign services, regulated by India's Controller of Certifying Authorities, were not affected.

Take that as the vendor's and CERT-In's position, and ask your own questions. On the Mozilla bug, a participant asked whether the continuing signature business uses the non TLS roots emSign Root CS CA - G2 and G3 and emSign Root SMIME CA - G1 and G3, and how they will meet the Baseline Requirements. No answer was recorded on 22 October. If you use eMudhra for code signing, S/MIME or enterprise PKI, ask:

• Which roots and intermediates issue your certificates, and were any created in the same April 2025 ceremony?
• Have those keys been independently checked since 17 October?
• Will the root cause report cover them?
• If emCA or CertiNext runs your internal CA, who generated your CA keys, on which HSMs, and what checks confirmed the key parameters?

The last one matters even if you never bought a TLS certificate. A private PKI built on the same tooling deserves the same key parameter check the public one failed.

What changed since first reports

Open questions

• Which partners will issue the free replacements, under which roots, and on what dates?
• When does the G1 RSA transition end, and what happens to G1 trust in each root program after that?
• Will the root programs act on the G1 hierarchy given the CRL signing reports and the open questions?
• How many G3 certificates had been replaced by 27 October, broken down by issuing CA, as Chrome requested?
• What does the root cause report say about the April 2025 ceremony and about other ceremonies?
• How will eMudhra show that the roots used for its continuing signature products are sound?

We will update this post when primary sources answer any of these.

Common mistakes and troubleshooting

• Moving from G3 to G1 and stopping. That trades a deadline for a later one. Plan the second move now.
• Checking only the invoice. Most of the G3 certificates were issued under a separately branded service. Check the chain on the wire.
• Forgetting CAA. The new CA refuses to issue and the error looks like a validation failure. Run dig CAA first.
• Switching the server before the app pins. Mobile clients with old pins fail hard and you cannot roll them back quickly.
• Serving the leaf without the new intermediate. Browsers may fetch the missing intermediate; API clients usually do not. Always test with openssl s_client -showcerts and with curl.
• Leaving the old certificate on a forgotten listener. Steps 1 and 2 exist because the same certificate lives on load balancers, CDNs, appliances and keystores.
• Removing G1 from OS trust stores yourself. That breaks legitimate sites. Wait for the root programs and your distribution.
• Assuming "not affected" for signing products means "no questions." Ask which roots, which ceremonies and which checks apply.
• Disabling verification to get past an error. As our explainer covers, fix the chain and never turn verification off.

Troubleshooting a failed ACME switch:

What would have helped

Practices any team can use

Treat your CA as a critical supplier. Most vendor risk programs list cloud providers and payroll systems, then forget the company whose roots every customer connection depends on. Record which CA issues each certificate, the contract terms, and an exit plan.

Keep a second CA ready. A tested ACME account with a second issuer, CAA records that already authorise it, and a runbook for switching turns a CA exit into an afternoon. eMudhra's own number, about 97% of the G3 certificates issued through ACME, shows how much of this can be automated.

Inventory certificates where they are served, not where they were bought. CT search, endpoint scans and keystore searches together give you the real list. Our post on what a certificate authority does explains the chain you are checking, and certificate authority compromise risks covers why the issuer matters.

Pin carefully, if at all. Pins tie your clients to a CA's business decisions. If you pin, always ship backup pins from a second issuer.

Use ARI aware ACME clients. RFC 9773 lets a CA ask clients to renew early. That only helps if your client listens.

Monitor CT for your domains. It shows mis-issuance after the fact and confirms your migration finished.

For your own PKI, check key parameters independently. The lesson of the April 2025 ceremony applies to any internal CA: an automated check of every generated public key, run by someone outside the ceremony team, catches this whole class of error.

Where Safeguard fits

Safeguard helps with the software side of this migration. It does not manage your certificates.

• Finding trust bundles in what you build. SBOM and dependency scanning covers repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, so "which images still ship the old ca-certificates package" or "which services pin certifi below 2026.10.19" is a query. See SBOM incident response.
• Matching the Go advisory. Vulnerability matching against vulnerability databases picks up identifiers such as CVE-2026-111943 in Go components, and reachability analysis helps rank which hits matter first.
• Keeping old versions out. Policies and gates evaluated in the platform can hold back builds that still carry an outdated bundle or toolchain.
• Making the changes with approval. The Safeguard CLI assistant can edit code and run commands with your approval. In this migration that means changing a cert-manager issuerRef, adding backup pins in a mobile app's configuration, or updating a Dockerfile, then running the checks above. Its /permissions modes run from Ask through Accept edits, Plan and Auto (the default) to Strict. safeguard exec runs a single non interactive turn for CI. The desktop and phone apps can send that work to a computer running the CLI and approve each command.

Where it does not help: Safeguard does not inventory the certificates deployed on your endpoints, load balancers or CDNs; use CT and the scans above for that. It does not choose or contract a CA, does not monitor CT, and cannot assess any CA's key ceremony or HSM controls. It would not have prevented this incident or the exit.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. A CA's key generation and a CA's business decision are outside that scope.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. It helps on the client side, such as confirming the fixed Go versions for CVE-2026-111943. Trust store changes without a CVE need the tracking site and vendor notes as well.

Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge on regression. We are not claiming Gold shipped an eMudhra related fix early. The habit it supports is the useful one here: pull patched, signed base images from a curated source and rebuild fast when trust changes upstream.

FAQ

Is eMudhra still a trusted certificate authority?

For TLS, partly and temporarily. emSign ECC Root CA - G3 is removed by Mozilla and scheduled for removal by Chrome on 27 October. The G1 RSA roots remain trusted and, per eMudhra, keep serving customers until the transition completes. Mozilla said on 20 October it was not removing emSign Root CA - G1 at that time.

My certificate chains to G1. Do I have to do anything?

Not urgently, but yes. Your certificate works today. The issuer has announced it is leaving the TLS business without a date, so put a move to another CA on your plan, and do it before your next renewal if you can.

Will eMudhra really replace my certificate for free?

The press release says eMudhra will contact affected customers and replace certificates free of cost from partners. It does not name the partners or roots. Ask for those details in writing before you rely on the offer.

When does the G1 hierarchy stop?

No date has been given. eMudhra says G1 continues until the transition is complete and that status services run until every issued certificate has expired or been replaced.

Did anyone misuse the weak keys?

eMudhra says no end-entity certificates were issued from the affected CAs and that no data was breached. That is eMudhra's claim. Google found no TLS certificates from the affected intermediates in CT before its block. No misuse has been reported, and the root cause report is still pending.

Is CVE-2026-111943 the eMudhra vulnerability?

It is the Go standard library's identifier for adding a denylist of the compromised intermediates to crypto/x509. It affects Go before 1.26.10 and 1.27.0 before 1.27.3. It is about clients trusting the bad intermediates, not about your server certificates.

Are eMudhra's digital signature and eSign products affected by the exit?

eMudhra says they continue unchanged and run on separate infrastructure, and CERT-In said the domestic DSC and eSign services were not affected by the key incident. Questions on the Mozilla bug about which roots those products use were still unanswered on 22 October.

Should I remove emSign roots from my servers' trust stores?

Not by hand for the public stores. Update your OS, runtimes and images so they reflect the root programs' decisions, which already drop G3. In private trust configurations you control, such as mTLS bundles, decide with your partners and replace public roots with your own CA where you can.

How do I find certificates I did not know about?

Search CT for your domains with crt.sh, scan your listeners with openssl s_client, and search hosts, keystores, Kubernetes secrets and provider certificate stores for an issuer containing emSign. The commands are in steps 1 and 2.

Does a CAA record protect me from the weak keys?

No. CAA tells honest CAs whether they may issue for your domain. It does nothing about certificates already issued or forged with a stolen key, and RFC 8659 says relying parties must not use it for validation. It is still worth updating as part of the move.

Fix it without waiting for upstream

For this incident, upstream means two things: the trust store and runtime releases that remove the bad chains, and the CA decisions that set your migration deadline. You cannot speed up a CA, but you can make sure the fixed bundles and toolchains reach every image you ship.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, and runs install and tests with approval. For this migration, you would use the same loop in your infrastructure repository: ask it to switch a cert-manager issuerRef to the new ClusterIssuer, or to bump certifi and rebuild an image, and approve each command. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The local runner demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. Here, you would run it on the build host for your service images and scan them for the ca-certificates package and Go toolchain versions that still trust the old chain.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. During a weekend cutover before 27 October, that is how an on call engineer could approve a certificate deploy or an image rebuild without being at a desk.

Click through it at your own pace, or open it full screen.

To find every image and service that still ships an old trust bundle, download Safeguard and follow the CLI docs. For the background on CERT-In's role, see our guide to CERT-In directives; for the wider month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• eMudhra: eMudhra to exit global SSL/TLS certificate business (press release, 22 Oct 2026)
• Mozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates
• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• CVE-2026-111943 record (CVE Services API)
• eMudhra incident tracking and test site
• Tracking site data: roots.json
• crt.sh: emSign Root CA G1 (ID 713599963)
• crt.sh: emSign Root TLS CA G1, self signed (ID 12478656983)
• crt.sh: emSign Root TLS CA G1, cross certificate (ID 14658191777)
• crt.sh: search for emSign Root CA G1
• crt.sh: search for emSign Root CA C1
• RFC 9773: ACME Renewal Information (ARI) Extension
• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record
• Reuters via Yahoo Finance: Indian firm eMudhra exits global SSL/TLS certificate business
• The Next Web: eMudhra exits global TLS certificate business
• Cycle: 2026 intermediate CA compromise
• Hacker News discussion of the exit announcement

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.