The eMudhra certificate compromise: what it means for Maximo

The certificate problem outside Maximo

An integration can work perfectly while trusting something it should not. It can also stop working after a perfectly sensible security update.

The eMudhra certificate incident gives Maximo administrators a reason to check both possibilities.

Check the certificate chains serving your Maximo URLs and external integrations, then identify which trust configuration each client actually uses. A browser receiving protection does not establish that your application runtime has received equivalent protection.

This article assesses the implications for Maximo 7.6 and Maximo Application Suite (MAS). It does not report a reproduced Maximo exploit or a tested product fix. Incident information was checked on 22 October 2026; follow the linked advisories for subsequent changes.

What happened?

On 17 October, Google received a report that eight eMudhra intermediate CA private keys were compromised because they had been generated with insufficient randomness. Such keys could allow fraudulent HTTPS certificates to be created for clients that still trust the affected hierarchy. Google's incident report explains the finding and response.

An intermediate CA is allowed to issue certificates beneath a trusted root. If someone else can recover its private key, they may be able to impersonate a service to a client accepting those certificates, provided they can also intercept or redirect the connection.

The public Mozilla incident record identifies six TLS intermediates and two code-signing intermediates, including cross-signed certificates. This article concentrates on HTTPS and its implications for Maximo.

eMudhra states that the affected intermediates had issued no end-entity certificates and that its root private keys were not affected. Those are the CA's statements during an ongoing investigation; distrust of a root and compromise of its private key are different events.

The private key was literally 4

“Insufficient randomness” sounds like a subtle cryptographic problem. Here, the numbers make it rather less subtle.

These are the eight compromised private scalar values, written in decimal. Each was independently checked for this article by deriving its P-384 public key and comparing it with the corresponding certificates in the public incident certificate inventory, including their cross-signs.

These are private-key numbers, not passwords, certificate serial numbers or fingerprints. Mozilla's technical investigation confirms that all eight were below 256.

Why is that so bad?

For this elliptic-curve system, the private key is a secret integer, conventionally called d. Its public key is a curve point calculated as Q = d × G, where G is a publicly known base point. The multiplication here is elliptic-curve scalar multiplication.

A correctly generated P-384 scalar is selected unpredictably from the valid range, which contains roughly 2^384 possibilities. That does not mean P-384 provides 384-bit security: generic attacks on a properly generated key take roughly 2^192 work. Both numbers are enormously beyond a few hundred guesses.

Here, every scalar fitted into one byte. Once you test the small-number range, there are only 255 nonzero candidates to check. Calculate each candidate's public point and compare it with the public key in the certificate. A match identifies the secret. For d = 4, the matching public point is simply 4 × G.

The curve was still P-384. The certificate could still describe a 384-bit key. Padding 4 with leading zeroes to fill 48 bytes does not create unpredictability.

This is like fitting an excellent lock and choosing a combination from 1 to 255. The lock's engineering cannot rescue the choice of secret.

For Maximo administrators, the consequence is that protecting the original key inside an HSM cannot stop someone independently calculating the same value. Recovered CA signing keys can enable fraudulent certificates; the relevant clients must stop accepting the compromised hierarchy through the applicable trust updates.

Two changes to trust, two things to check

Browser vendors have already distributed targeted protection. Mozilla blocked affected certificates through OneCRL and is removing the signing root from NSS to help protect consumers that do not receive OneCRL. See Mozilla's response.

Google blocked the affected intermediate public keys through Chrome's CRLSet. It also announced removal of emSign ECC Root CA - G3 from the Chrome Root Store, expected to reach relevant stable devices on 27 October 2026, in the morning Pacific time. Legitimate certificates under that root can consequently stop working. Google instructs affected operators to replace them through another trusted hierarchy. Google's announcement contains the timetable.

That creates two separate questions:

“The browser opens it” answers neither question for an outbound Java integration.

What an attacker could do to a Maximo integration

Suppose an outbound Maximo integration sends data to https://api.example.com. An attacker holding one of the compromised TLS intermediate CA keys could sign their own certificate naming api.example.com, without owning that domain or obtaining its genuine server's private key.

If the attacker can also intercept or redirect the integration's connection, they could present that fraudulent certificate from a server they control. If Maximo's HTTPS client accepts the chain and its other validation requirements are satisfied, it could establish an encrypted connection to the attacker while believing it is talking to the real API. The compromised CA keys and interception risk are described in Google's incident report.

In this scenario, the attacker could potentially read credentials and business data sent over that connection, alter responses, or relay traffic to the genuine API while reading or modifying it. TLS encryption would still be present; the problem is that it terminates at the wrong party. This is a possible attack scenario, not an attack observed against Maximo in this article.

The compromised intermediate does not have to appear directly in Maximo's truststore. The attacker can supply it as part of the certificate chain. Trust in a parent root can be enough if the client builds an acceptable path to that root and no applicable blocklist, revocation check or other validation rule rejects the chain.

The genuine API's existing certificate could even come from a completely different, unaffected CA. What matters for this attack is whether the integration client accepts the attacker's alternative certificate for the same hostname. Checking only the genuine endpoint's certificate is therefore not enough: check the client's effective trust and distrust policies too.

Where to look in a Maximo installation

Start with the connection, rather than assuming there is one truststore for the whole environment.

For traditional Maximo installations, include WebSphere SSL configurations and managed truststores in the review. For MAS, include the relevant application containers, Java configuration and mounted or imported certificates. These are inspection targets, rather than a claim that every deployment uses the same configuration.

Updating a node's operating system does not automatically prove that a separately packaged runtime, container image or custom truststore has changed. Establish where each client obtains its trust material and how that material is updated.

Certificates: distributed configuration with an expiry date. Naturally, everybody remembers exactly where they imported them.

What Red Hat says

RHSB-2026-012 covers RHEL 6–10 and identifies potential impact on products using RHEL, including CoreOS, OpenShift and RHEL/UBI-based containers. Red Hat advises applying updated ca-certificates packages as they become available and rebuilding customer containers when updated base images are available.

The bulletin also provides mitigation guidance involving related roots, including cross-signing through Comodo AAA Services. Use that guidance to determine the scope of a mitigation; removing only a root whose name contains emSign may not address every relevant path.

For an OpenShift deployment, follow supported platform and application update procedures. A package change made inside a running pod is not a durable image update.

Inspect the certificate your endpoint serves

From a machine with OpenSSL, use your environment's hostname:

openssl s_client \
  -connect maximo.example.com:443 \
  -servername maximo.example.com \
  -showcerts </dev/null

Repeat for external integration endpoints. This is an inventory command: -showcerts shows certificates supplied by the server, not necessarily the complete path a particular client constructs. Roots are often omitted, and successful command execution is not proof that the endpoint passes your application's validation policy.

Look for issuer names such as eMudhra, emSign and emSign ECC Root CA - G3, then compare exact certificates and fingerprints with the vendor incident records. A name match is a lead to investigate, not proof that a certificate's private key is compromised.

Check the public URL from the network your users actually use. A reverse proxy or TLS-inspecting gateway can mean different clients receive different certificates.

Inspect the trust configuration actually in use

On a relevant RPM-based system, inventory the installed package:

rpm -q ca-certificates

Compare it with current errata for that supported release in Red Hat's bulletin. The package version alone does not describe a custom Java truststore.

Where supported by the selected JDK, inspect its default CA store with:

keytool -list -v -cacerts

Use the keytool belonging to the runtime you intend to inspect. Do not assume the Java installation on your workstation is the one running Manage. If the application uses a configured truststore, inspect that store instead through the relevant runtime or application-server tooling.

Also check explicitly imported intermediates and custom trust bundles. An imported certificate can change the trust path, so inventorying only the default roots is incomplete.

Apply the update, then test the connection

For each relevant connection, record the endpoint, certificate chain, client runtime, truststore owner and supported update mechanism. Apply the appropriate vendor updates or mitigation, replacing server certificates that depend on a hierarchy the client is removing.

Test the integration from its actual runtime and network path. A desktop browser test is useful for browser access; it does not exercise an outbound publish channel, automation script or middleware client.

After changes, investigate new errors such as:

javax.net.ssl.SSLHandshakeException
PKIX path building failed
unable to find valid certification path to requested target

These are illustrative TLS validation errors, not incident symptoms reproduced here. They can also result from missing intermediates, unrelated trust configuration or other certificate problems.

Keep certificate validation enabled. Importing a rejected certificate simply to make an error disappear can undo the protection you were trying to apply.

What to do first

1. Check whether any Maximo-facing or integration endpoint chains to emSign ECC Root CA - G3, with Google's announced 27 October change in mind.
2. Identify all relevant clients and their effective trust configuration, including clients that do not use browser blocklists.
3. Follow current vendor guidance for the platform, runtime and application images; assess custom truststores separately.
4. Test affected connections and retain evidence of the new chain and update level.

The question is not simply whether Maximo still works. It is whether each connection still trusts the right things.

Invisible Bits of Maximo. Very visible when they stop working.