eMudhra CA Distrust: Audit Your Login TLS Certificates Now

Chrome, Firefox, Apple and Microsoft have all stopped trusting eight eMudhra intermediate certificate authorities after their private keys turned out to be recoverable from the certificates themselves, and Chrome and Firefox have gone further and removed the emSign ECC Root CA - G3, the root above them (NSS 3.131.1 release note). Google scheduled that removal for the morning of 27 October 2026, Pacific time (Google), so any TLS certificate that chains to it should already be failing in Chrome. If you run a login page, an OpenID Connect issuer or a SAML identity provider, check its certificate chain now, replace anything that chains to emSign, and then check the other direction: the truststore your Keycloak uses when it calls LDAP, SMTP and brokered identity providers.

Key Takeaways

• Chrome and Firefox removed the emSign ECC Root CA - G3, not just the eight intermediates, so certificates under that root stop working in Chrome from 27 October 2026 (Google).
• Check three endpoints on each login hostname: the login page, the OIDC discovery and keys URLs, and the SAML descriptor.
• Keycloak trusts the Java default truststore in its image on every outgoing call to LDAP, SMTP and brokered identity providers, and its own options only add certificates to that truststore, never remove them (Keycloak).
• SAML and token signing certificates in Keycloak are self-signed and are not affected unless a partner uses a CA-issued signing certificate.

This post is for the team that saw the headline and runs authentication infrastructure. The news coverage explains the browser decision and stops there, so we add the identity-specific part: a copy-paste chain check for the three kinds of endpoint that matter, why a distrusted chain on an identity provider is worse than one on an ordinary website, what the Keycloak truststore has to do with it, a clear note on which signing certificates are not affected, and an order for the replacement work.

What happened to eMudhra’s intermediate CAs?

eMudhra is an Indian certificate authority whose public TLS hierarchy is branded emSign. On 17 October 2026 a researcher reported to Mozilla, Google, Apple, Microsoft and eMudhra that the private keys of eight of its intermediate CAs could be recovered from the public certificates, and Mozilla’s engineers confirmed it and recovered the keys themselves within two hours (Mozilla Bugzilla, bug 2083449). The cause was not a leak but bad key generation. Dennis Jackson of Mozilla wrote in that bug that “P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256”, so anyone could recover them “near instantly” (Mozilla Bugzilla). The Register reported that Scott Helme and other researchers found the eight values to be 4, 56, 66, 115, 155, 156, 230 and 237 (The Register, 20 October 2026).

Six of the eight are TLS intermediates, named EM DV, OV and EV TLS CA - G3B and G3C, and two are code-signing intermediates, EM OV CS CA - G3B and G3C. Mozilla’s bug lists their issuers as emSign Root TLS CA - G3 and emSign Root CS CA - G3 (Mozilla Bugzilla), and Google places the whole set under the root it removed from the Chrome Root Store, emSign ECC Root CA - G3 (Google), so when you read a chain, look for all three names and for emSign in general. Qualys published their serial numbers and SHA-256 fingerprints, which you will want for the check below (Qualys, 23 October 2026). eMudhra’s own account is that “a script error resulted in issuing CA’s with weak keys” when the eight intermediates were created on 30 April 2025 (eMudhra statement). The company’s own disclosure, quoted in Mozilla’s bug, says that “there were human errors in multiple steps of the process that resulted in significant flaws in the key lifecycle integrity process” (SecurityWeek, 21 October 2026, Mozilla Bugzilla).

Two facts shape what you have to do. First, eMudhra says that none of the eight intermediates issued a customer certificate (eMudhra statement), and Certificate Transparency logs show no misuse before the revocation, although anyone could have recovered the keys at any time since April 2025 (SecurityWeek). Second, the browsers did not stop at the eight. Because the keys were weak from birth, Mozilla and Google removed trust in the root above them, and that removal takes down legitimate certificates that were never issued by the compromised intermediates. By Chrome’s count of public Certificate Transparency logs, about 30,800 unexpired certificates chained to that root as of 21 October, as The Hacker News reported (The Hacker News, October 2026). On 22 October eMudhra announced that it is leaving the global SSL/TLS certificate business altogether, which it says brings in about 1% of its revenue (The Hacker News), so a certificate from any emSign root needs a replacement plan, not just the ones under the G3 ECC root.

When does each browser and platform stop trusting it?

The dates differ by vendor and by what they distrusted. Blocking the eight intermediates happened within days everywhere. Removing the root is the step that breaks certificates issued through other emSign intermediates, and Google scheduled it for 27 October in Chrome. Both root programs publish the rules they act under, in the Chrome Root Program policy and Mozilla’s CA program.

Apple’s note about command-line tools matters most for an identity team, and its lesson is wider than macOS. Browsers get out-of-band block lists; most other TLS clients only get a new trust store when their package or runtime updates. Mozilla said as much about NSS 3.131.1: it “helps protect downstream users beyond Firefox who don’t receive revocation information or cannot block intermediate certificates” (NSS 3.131.1 release note). Go shipped the block in 1.27.3 and 1.26.10 (BleepingComputer), Python’s certifi in 2026.10.19, and Endor Labs notes that the JDK’s own cacerts keystore was not on the fixed list when it wrote its roundup, so Java services count as unconfirmed until your JDK vendor publishes an update (Endor Labs). Keycloak is a Java service, which is why this post has a truststore section.

Why is a distrusted chain worse on an identity provider than on a website?

A website with a bad certificate loses its own visitors. An identity provider with a bad certificate loses every application that redirects to it, because single sign-on puts one hostname in the path of all of them. Your login page, the OpenID Connect authorization and token endpoints and the SAML single sign-on endpoint usually share that hostname, so one chain failure means nobody can sign in to anything, and the error appears in each application’s name rather than yours.

Server-to-server calls fail more quietly. An application’s OpenID Connect library fetches the discovery document and the signing keys from the issuer over HTTPS; Keycloak publishes them at /realms/{realm-name}/.well-known/openid-configuration and /realms/{realm-name}/protocol/openid-connect/certs (Keycloak, OpenID Connect layers). A SAML service provider fetches your identity provider metadata from /realms/{realm}/protocol/saml/descriptor (Skycloak docs, using Keycloak as a SAML IdP). When those fetches run from a language runtime whose trust store has already dropped the root, they fail with a chain error that lands in an application log, not in a browser, and the symptom is a token validation failure at startup or at the next key refresh. On the Keycloak side the matching symptom is PKIX path building failed on an outgoing call, which our SSL certificate error guide identifies as the sign of a certificate that is not in Keycloak’s Java truststore.

The browsers acted on a second reason, and it applies to you as well. A recoverable intermediate key lets an attacker mint a certificate for your login hostname that every unpatched client accepts. On a static site that enables a convincing phishing page. On an identity provider it enables a transparent interception of the login itself, including the password and the authorization code, for any client that has not received the block.

How do I check whether my login endpoints chain to eMudhra?

Run the check from a machine with a current openssl, against the exact hostname your users and applications use, and against each of the three endpoint kinds, because a reverse proxy or a load balancer can serve a different certificate per hostname. The command prints the chain the server sends; you are looking for an issuer or a subject containing emSign or eMudhra anywhere in it. SSL.com suggests the same search (SSL.com).

# The login page, the OIDC issuer and the SAML IdP usually share a host; check each host you expose.
for host in login.example.com auth.example.com; do
  echo "== $host"
  openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
    | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
    | openssl pkcs7 -print_certs -noout \
    | grep -E 'subject=|issuer='
done

A clean result shows a subject and issuer per certificate with no emSign or eMudhra name in any of them. If one appears, the certificate needs replacing whether or not it was issued by one of the eight, because of the root removal. Count any EM DV, OV or EV TLS CA - G3B or G3C subject as a hit whatever issuer sits above it, because cross-signed copies of eMudhra certificates exist, such as the AAA Certificate Services cross-sign Microsoft removed (BleepingComputer), and a search for emSign alone would miss them. To match the eight intermediates exactly, compare SHA-256 fingerprints with the list Qualys published (Qualys):

openssl s_client -connect login.example.com:443 -servername login.example.com -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERT/{c++} {print > ("chain-" c ".pem")}'
for f in chain-*.pem; do openssl x509 -in "$f" -noout -subject -fingerprint -sha256; done

Then check the endpoints the way an application sees them, with the trust store of the runtime that will do the fetching. The point of running these from the application’s own container image is that its trust store, not your laptop’s, is the one that decides:

# OIDC discovery and the signing keys, as an OIDC library fetches them
curl -sS -o /dev/null -w '%{http_code}\n' https://login.example.com/realms/myrealm/.well-known/openid-configuration
curl -sS -o /dev/null -w '%{http_code}\n' https://login.example.com/realms/myrealm/protocol/openid-connect/certs

# SAML IdP metadata, as a service provider fetches it
curl -sS -o /dev/null -w '%{http_code}\n' https://login.example.com/realms/myrealm/protocol/saml/descriptor

A curl chain error here tells you which trust stores have already dropped the root. A 200 from a runtime whose trust store still contains it tells you nothing about whether the chain is safe, which is why the openssl check comes first.

If Keycloak sits behind a reverse proxy that terminates TLS, the certificate you are checking belongs to the proxy, and that is where you replace it; our reverse proxy guide covers the setup. If Keycloak terminates TLS itself, the certificate is the one named by https-certificate-file and https-certificate-key-file, or the keystore named by https-key-store-file (Keycloak, configuring TLS).

What about the Keycloak truststore and outgoing connections?

The server certificate news covers only the inbound direction. Keycloak also acts as a TLS client every time it talks to an LDAP directory, sends mail over SMTP, or calls a brokered identity provider for discovery, tokens and user info, and the certificates it accepts on those calls come from its truststore. Keycloak’s documentation says that “the existing Java default truststore certs will always be trusted”, that you add your own with --truststore-paths, as PEM files or PKCS12 files, and that the result is the truststore Keycloak uses when it “communicates with external services” (Keycloak, configuring trusted certificates).

That default is the problem here. Keycloak’s documentation describes no block list of its own for outgoing calls; the Java default truststore in its image “will always be trusted” (Keycloak), and Endor Labs could not confirm a JDK update at the time of its roundup (Endor Labs). So an unpatched Keycloak keeps accepting a certificate forged with one of the eight keys on its outgoing calls, and the targets that matter are the ones that carry credentials: the LDAP bind, the SMTP login, and the token endpoint of each brokered provider. Two checks cover it:

1. List what Keycloak calls out to. Every LDAP user federation URL, every SMTP host in realm settings, and every brokered OpenID Connect or SAML identity provider’s issuer. Run the openssl chain check above against each. A partner whose chain goes through emSign is on your list for the replacement order below.
2. Check what the Keycloak image trusts. The JDK inside the container decides, so find out which trust store it has and whether your JDK vendor and base image have shipped the removal. Until they do, the exposure is theoretical, since no misuse has been observed, but it is also silent, so note the date you checked and re-check when the image updates.

The same page states that LDAP secure connections always require strict hostname checking and that the tls-hostname-verifier option does not apply to them (Keycloak, configuring trusted certificates); our CVE-2026-35563 post goes through what that means for LDAP user federation. While you are in those settings, confirm that the LDAP connection is not configured to skip certificate validation, because a truststore update protects nothing on a connection that never checks.

Are SAML signing and token signing certificates affected?

Mostly not, and the difference between the two kinds of certificate causes most of the confusion. The certificates in this incident are TLS certificates, which prove that a hostname belongs to you and which browsers and HTTP clients validate against a public trust store. The certificate in your SAML metadata, and the keys behind your OpenID Connect tokens, are something else: they sign assertions and tokens, and the relying party validates the signature against a key it was configured with, not against a certificate authority.

Keycloak generates those keys itself. When a realm is created, “a key pair and a self-signed certificate is automatically generated”, and the rsa-generated provider is how you add another (Keycloak, realm keys). The certificate in your SAML descriptor is that self-signed certificate, and no browser root program has any say over it. The same is true in the other direction: when Keycloak brokers an external SAML identity provider, the validating certificate imported from the partner’s metadata is what checks the assertion signature, as our SAML service provider guide shows. Validation is a comparison with that stored certificate, so the emSign distrust does not change its outcome.

The exception is a partner who signs SAML assertions with a certificate issued by a public CA rather than a self-signed one, and a relying party that insists on PKI validation of signing certificates. Both are unusual, but if a partner tells you they are replacing their signing certificate because of this incident, treat it like any signing key rotation: import the new certificate before they switch, and keep the old one until they have.

In what order should we replace certificates?

Replace from the centre outward, because the identity provider is what everything else depends on, and because you want the first replacement to be the one that fixes the most users.

First the identity provider’s login hostname gets a new chain (1), then the applications and SAML service providers that redirect to it (2), then the federated partners, LDAP and SMTP servers Keycloak calls out to, and the Keycloak truststore where a partner used a private CA (3), and the chain check runs again on every hostname (4).

1. The identity provider first. Get the new certificate from a different hierarchy; Google’s advice is that operators “must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store” (Google). On a Keycloak that terminates TLS itself, drop the new files into place and let https-certificates-reload-period pick them up; the documentation says reloading runs hourly by default and allows a rotation “without a server restart” (Keycloak, configuring TLS). Keep the keystore password out of the command line and the config file, as that page asks; our vault post covers where to keep it instead.
2. Then the applications and service providers. Each one that users reach directly needs its own replacement, and each one that fetches your metadata or keys over HTTPS needs a trust store that accepts your new chain, which is almost always the case when the new issuer is Let’s Encrypt, Google Trust Services, DigiCert or another widely carried root.
3. Then the federated side. Ask each brokered identity provider, LDAP host and SMTP relay on your list from the truststore section to replace theirs, and if a partner replaces a private CA certificate you had added with --truststore-paths, update the file on your side at the same time.
4. Then re-run the check and keep it running. Put the openssl loop in a scheduled job that fails on any emSign or eMudhra match and on any chain that fails to verify, and watch Keycloak’s logs for new PKIX path building failed lines, which mark an outgoing call whose chain just stopped validating. While that job is in place, our Keycloak security audit and hardening checklist is the broader review to run on the rest of the server.

Are Skycloak endpoints affected?

Not on custom domains. Skycloak provisions the TLS certificates of custom domains automatically through Cloudflare for SaaS (Skycloak docs, custom domains). For publicly trusted certificates, Cloudflare lists its partner certificate authorities as Let’s Encrypt, Google Trust Services, SSL.com and, for backup certificates only, Sectigo, and eMudhra is not among them (Cloudflare docs, certificate authorities). On the outgoing side, every cluster is fully managed and Skycloak handles the servers and their updates (Skycloak docs, overview), so the image trust store that this post asks you to check is ours to keep current.

Frequently asked questions

My certificate was issued by eMudhra but not by one of the eight intermediates. Do I still have to replace it?

Yes, if it chains to emSign ECC Root CA - G3, because Chrome, Firefox and Apple removed or blocked that root and not just the eight intermediates. Google warned that legitimate certificates chaining to the root would stop working in Chrome on 27 October (Google), and Microsoft noted that removing a root “is a separate trust decision, broader than blocking the identified compromised intermediate keys” (BleepingComputer). A certificate under one of eMudhra’s other roots works for now, but with eMudhra leaving the TLS business, plan its replacement too.

Our login page passes the check. Are we done?

Not until you have checked the outgoing direction. Keycloak trusts the JDK’s default truststore on every call to LDAP, SMTP and brokered identity providers (Keycloak), and nothing in Keycloak’s own configuration removes a certificate from it, so the JDK in the image is what has to change. Check what your image trusts, and check the chains of the servers Keycloak calls.

Does Keycloak’s --truststore-paths let me remove a root?

No. The option adds certificates to trust on top of the Java default truststore, which the documentation says “will always be trusted” (Keycloak). The documentation describes no option for removing one, so taking a root out means changing the Java default truststore inside the image itself.

Was anyone actually attacked with these keys?

Nothing public says so. eMudhra states it is “not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed” (eMudhra), and Cloudflare’s review found no active exploitation on its services (Cloudflare). Mozilla’s bug records 107,107 certificates signed with six of the eight keys being logged to Certificate Transparency between 20 and 21 October, after disclosure, 106,050 of them proof-of-concept certificates whose only name is google.com (Mozilla Bugzilla). The keys were recoverable from the day they were made in April 2025 until the block in October 2026 (Mozilla Bugzilla), so the browsers acted on what was possible rather than on what was observed.

What to do today

Run the chain check against every login hostname, the OIDC discovery URL and the SAML descriptor URL, from a machine with a current trust store, and replace anything whose chain names emSign or eMudhra now, because Chrome already rejects it. Then list the LDAP, SMTP and brokered identity provider hosts your Keycloak calls, check their chains too, and find out whether the JDK in your Keycloak image has dropped the root yet. Leave your SAML and token signing keys alone unless a partner tells you they are rotating theirs.

If certificate rotation on your login hostnames is work you would rather not own, Skycloak custom domains get their certificates through Cloudflare, from the certificate authorities Cloudflare lists, and Skycloak handles the servers and updates behind them (Skycloak docs, overview). See how managed Keycloak hosting works and leave the certificate renewals to us.

Sources

• SecurityWeek, “Browsers Block eMudhra Intermediate CAs Over Recoverable Private Keys”, 21 October 2026, retrieved 2026-10-27, https://www.securityweek.com/browsers-block-emudhra-intermediate-cas-over-recoverable-private-keys/
• Mozilla Bugzilla, bug 2083449, “eMudhra: Private key compromise of Intermediate Certificates”, retrieved 2026-10-27, https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Google, “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates”, 20 October 2026, retrieved 2026-10-27, https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
• NSS 3.131.1 release announcement, oss-security, 20 October 2026, retrieved 2026-10-27, https://www.openwall.com/lists/oss-security/2026/10/20/30
• Apple Support, “About the compromised eMudhra intermediate CAs”, retrieved 2026-10-27, https://support.apple.com/en-us/149555
• BleepingComputer, “Microsoft releases Windows OOB updates to distrust eMudhra certificates”, retrieved 2026-10-27, https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-windows-oob-updates-to-distrust-emudhra-certificates/
• BleepingComputer, “Mozilla, Google, Apple block compromised eMudhra CA certificates”, retrieved 2026-10-27, https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/
• The Hacker News, “eMudhra to Exit Global SSL/TLS Business After 8 Intermediate CA Keys Found Easily Guessable”, October 2026, retrieved 2026-10-27, https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html
• eMudhra, “Statement on Recent Certificate Security Incident”, retrieved 2026-10-27, https://emudhra.com/en/post/certificate-security-incident
• Cloudflare, “8 eMudhra certificates are compromised. Here’s what you need to know”, 20 October 2026, retrieved 2026-10-27, https://blog.cloudflare.com/emudhra-certificate-compromise/
• Cloudflare Docs, “Certificate authorities”, retrieved 2026-10-27, https://developers.cloudflare.com/ssl/reference/certificate-authorities/
• Cloudflare Docs, “Cloudflare for SaaS”, retrieved 2026-10-28, https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/
• The Register, “Indian certification authority eMudhra’s private keys compromised”, 20 October 2026, retrieved 2026-10-28, https://www.theregister.com/a/5304312
• Chromium, “Chrome Root Program Policy”, retrieved 2026-10-28, https://www.chromium.org/Home/chromium-security/root-ca-policy/
• Mozilla, “CA Certificate Program”, retrieved 2026-10-28, https://wiki.mozilla.org/CA
• Qualys, “How to Identify Compromised eMudhra Certificates With Qualys (CVE-2026-111943 and CVE-2026-111944)”, 23 October 2026, retrieved 2026-10-27, https://blog.qualys.com/product-tech/2026/10/23/how-to-identify-compromised-emudhra-certificates-with-qualys-cve-2026-111943-and-cve-2026-111944
• Endor Labs, “eMudhra CA Compromise: The Trust Stores You Didn’t Patch”, retrieved 2026-10-27, https://www.endorlabs.com/learn/emudhra-intermediate-ca-compromise-the-trust-stores-you-patched-and-the-ones-you-didnt-know-you-had
• SSL.com, “Check Your Certificates Before October 27: Chrome Is Removing an eMudhra Root”, retrieved 2026-10-27, https://www.ssl.com/article/check-your-certificates-before-october-27-chrome-is-removing-an-emudhra-root/
• Keycloak, “Configuring trusted certificates”, retrieved 2026-10-27, https://www.keycloak.org/server/keycloak-truststore
• Keycloak, “Configuring TLS”, retrieved 2026-10-27, https://www.keycloak.org/server/enabletls
• Keycloak, “OpenID Connect layers”, retrieved 2026-10-27, https://www.keycloak.org/securing-apps/oidc-layers
• Keycloak, Server Administration Guide, “Configuring realm keys”, retrieved 2026-10-27, https://www.keycloak.org/docs/latest/server_admin/index.html#realm_keys
• Skycloak docs, “Custom domains”, retrieved 2026-10-27, https://skycloak.io/docs/features/domain/
• Skycloak docs, “Overview of Skycloak”, retrieved 2026-10-28, https://skycloak.io/docs/getting-started/overview/
• Skycloak docs, “Using Keycloak as a SAML identity provider”, retrieved 2026-10-27, https://skycloak.io/docs/guides/using-keycloak-as-saml-idp/