TL;DR: Weakly generated intermediate CA keys can be recovered from public information and used to forge valid certificate chains that impersonate services, according to Upwind. Cloud workloads and server-side clients that trust the affected roots must treat revocation, runtime trust bundles and rebuilds as the real control boundary.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's research: A flawed set of eMudhra intermediate CA keys can be recovered and abused to forge certificate chains that impersonate services and cloud identities.
Why it matters: Cloud teams must understand which trust stores, runtimes and client paths actually validate certificates, because revocation alone does not protect server-side workloads that keep trusting affected chains.
Context
An intermediate certificate authority is a trust broker between a root CA and the certificates issued to workloads, services and signing pipelines. When that intermediate key is weak, the problem is not just leakage after the fact. The trust relationship itself is broken, and cloud identity controls that rely on X.509 inherit that failure. For teams managing service-to-service authentication, certificate lifecycle is part of identity governance, not a separate PKI concern.
Upwind's research shows the affected keys were generated so weakly that they could be derived from public information, which means defenders should assume forgery risk even before a visible abuse event. That matters because many cloud services treat client certificates as proof of identity, and many server-side runtimes do not enforce revocation consistently.
This is an atypical failure mode because the certificate chain can look mathematically valid while the underlying identity proof is false. In practice, that turns trust bundles, runtime defaults and rebuild discipline into security controls that need the same attention as access policy.
Key questions
Q: How should teams detect a compromised certificate chain?
A: Detect a compromised certificate chain by validating the leaf, intermediate and root against your own verifier and trust bundle, then checking for unexpected issuers, broken revocation status and path changes. Treat mismatched subject names, expired intermediates and sudden trust anchor additions as indicators that a chain may have been altered or abused.
Q: Why do revoked intermediates still work in some workloads?
A: Revoked intermediates can still work when workloads accept cached chains, do not enforce revocation checks, or trust a broader CA bundle than the intended path. Long-lived connections, offline validation and stale trust stores can let an old chain continue to authenticate until certificates, bundles or verifiers are refreshed.
Q: How do X.509 client certificates become cloud access?
A: X.509 client certificates become cloud access when a trusted X.509 certificate is mapped to an identity, role or workload claim by a provider, gateway or service. The certificate proof then acts as an authentication factor or federated credential, and the resulting permissions are limited by the mapped policy, not by the certificate alone.
Q: Can cross-signed certificates keep a CA compromise alive?
A: Yes. Cross-signed certificates can keep a CA compromise alive when multiple trust paths still validate the same leaf through an alternative issuer or root. If one path is distrusted but another remains in the trust store, clients may continue accepting the chain unless every trust path is removed or blocked.
Technical breakdown
How a compromised intermediate CA weakens certificate trust
An intermediate CA signs certificates on behalf of a trusted root, so it sits directly in the chain that clients validate. If the intermediate private key is weak or recovered, an attacker can create certificates with signatures that verify correctly even though the identity in the certificate is false. That matters because validation checks the chain, not the intent behind the key generation. In cloud and application environments, the trust decision is often delegated to libraries, proxies and platform stores, which makes the weakness propagate across services that share the same trust bundle. See the PKI Basics Guide.
Practical implication: Treat intermediate CA compromise as a trust-path failure and identify every runtime that consumes the affected chain.
Why revocation misses server-side workloads
Revocation helps when the client or platform actively checks it, but many non-browser TLS stacks do not. OpenSSL-based tools, language runtimes and embedded libraries often continue to trust a revoked chain until the local bundle or runtime is updated. That creates a gap between browser safety and workload safety. The issue is not that revocation failed globally, but that enforcement is inconsistent across execution environments, containers and server-side applications.
Practical implication: Inventory which runtimes actually enforce revocation and remove reliance on trust bundles that are only fixed at the host level.
How forged client certificates can become cloud access
Some cloud services accept X.509 client certificates as an identity proof for federation, mTLS or device access. If the trust anchor includes a compromised root or intermediate, a forged certificate can be exchanged for credentials or accepted as a legitimate client. That is an identity problem as much as a transport problem because the certificate becomes the assertion of who or what is connecting. The practical risk extends beyond browsers to workloads, load balancers, VPNs and IoT registries that treat certificate trust as an access decision.
Practical implication: Review every cloud trust anchor that maps X.509 to identity and remove affected roots, intermediates and cross-sign paths.
Threat narrative
Attacker objective: The attacker seeks to impersonate services or clients by turning a forged certificate chain into trusted access.
- Entry occurs through the compromised or weakly generated intermediate CA keys that can be recovered from public information.
- Credential abuse follows when an attacker uses those keys to mint a forged certificate chain that validates against trusted roots.
- Escalation happens when a cloud service, VPN, workload or signing flow accepts the forged certificate as proof of identity.
- Impact is impersonation, unauthorized access or software trust abuse across services that continue to trust the affected chain.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Weak key generation, not just key exposure, is the core governance failure here. Upwind's research shows the affected P-384 keys were so weak that they could be derived from public information, which means the control failure began at issuance time. That shifts the lesson from incident response to trust design, because a certificate authority that generates weak private keys creates a latent impersonation risk for every chain it signs. Practitioners should treat key generation quality as an identity-control requirement, not a PKI housekeeping task.
Certificate trust has become an identity boundary for cloud services. When a service accepts X.509 as proof of identity, a forged certificate is not just a TLS artifact. It is an access token with a different format. That is why the same compromised intermediate can affect mTLS, workload identity federation, VPN enrolment and software signing. Cloud security teams need to map where certificate trust is used as an authenticator, because those are the places where a compromised CA becomes an IAM problem.
Browser revocation and workload trust are no longer the same control. Browsers can absorb emergency trust updates quickly, but server-side software often waits on runtime updates, image rebuilds or embedded bundle changes. This creates a split-brain trust model in which one environment blocks the chain while another still accepts it. The named concept here is runtime trust drift: the gap between revoked public trust and the trust decisions actually made inside deployed workloads. Practitioners should govern that drift as a standing exposure, not a one-time patch issue.
Cross-signing multiplies the blast radius of a CA compromise. When the same intermediate reaches trusted roots through multiple paths, one weakness can survive a partial remediation and remain reachable through older trust stores or alternative bundles. That makes root-store hygiene and chain-path awareness part of the incident response model. Teams should assume that if any runtime still trusts an old path, the exposure remains live.
Code-signing keys widen the problem beyond TLS traffic. The incident is not limited to service impersonation. If a compromised key can sign code that endpoints and servers treat as trusted, the attack surface reaches software distribution, update pipelines and host trust decisions. Practitioners should therefore connect certificate governance to software supply-chain controls, not leave it isolated in network or web-security teams.
From our research library:
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
What this signals
Runtime trust drift: the practical risk is not only that a certificate authority key was weak, but that different workloads will continue to trust the same chain at different times. That creates a governance problem where patching a host does not equal fixing the application, especially when trust decisions live inside language runtimes, containers and serverless bundles.
Cloud security teams should expect more incidents where certificate trust behaves like an identity control rather than a transport control. Once X.509 is accepted as proof of identity, trust store hygiene, rebuild cadence and runtime verification become part of access governance, not just PKI operations.
For practitioners
- Map every trust store that matters Inventory operating system bundles, application-specific bundles, embedded runtime stores and environment-variable overrides for each workload that validates certificates.
- Remove affected roots and intermediates Delete the compromised trust anchors from mTLS stores, workload identity providers, VPN registrations and any certificate path that can still validate the chain.
- Rebuild workloads with fixed runtimes Patch language runtimes and rebuild containers, serverless packages and binaries so the application uses the corrected verifier rather than a stale host bundle.
- Verify trust from inside the workload Test certificate rejection using the application's own runtime and trust bundle, not only host-level tools, because curl or the shell may not reflect the deployed verifier.
Key takeaways
- The eMudhra compromise shows that weak CA key generation can undermine certificate trust even when no active misuse is immediately visible.
- The impact is wider than browsers because server-side runtimes, containers and cloud trust anchors may continue accepting the affected chain.
- Practical containment depends on removing affected trust paths, rebuilding workloads and verifying the application verifier, not just updating the host.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · CA Compromise and Mass Certificate Replacement Playbook · Cloud Security Guide · Secrets in Docker Hub images (RWTH Aachen study)
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Forged certificates become accepted identity assertions when trust anchors are mismanaged. |
| NHI-07 — Long-Lived Secrets | Weak CA keys behave like durable secrets that remain usable until runtimes and bundles change. | |
| Recommendation — Treat certificate-based workload trust as an authentication control and remove any path that accepts the compromised chain. Shorten the lifetime of CA trust material and force rebuilds that replace stale key material everywhere it is embedded. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key rotation, revocation and trust-store replacement are authenticator lifecycle controls. |
| Recommendation — Apply IA-5 to manage certificate and key lifecycle across roots, intermediates and runtime trust bundles. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cloud services use certificate chains to grant access and validate identities. |
| Recommendation — Tie certificate trust to authorization decisions and remove any entitlement path that still accepts the affected chain. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Forged certificates support credential abuse and movement into cloud services and workloads. |
| Recommendation — Map certificate forgery risk to credential access and lateral movement detections across cloud-facing services. | ||
Key terms
- Intermediate Certificate Authority: An intermediate certificate authority is a delegated signing layer that issues certificates on behalf of a higher-level root CA. In device trust programmes, it helps scale issuance while preserving separation of duties, but it also becomes a critical governance point because its policies shape device identity integrity.
- Certificate Chain: The linked sequence of trust relationships that lets a browser or client verify a certificate back to a trusted root authority. If any link in the chain fails, the certificate may be treated as untrusted even when the endpoint itself is correctly configured.
- Cross-Signed Certificate: A cross-signed certificate is the same trust-bridge concept expressed from the signing relationship. One CA signs another CA’s certificate so that relying parties can build more than one valid chain. This is commonly used when introducing a new root while older devices still depend on an existing trust anchor.
- Certificate Revocation: Certificate Revocation is the act of marking a certificate as no longer trustworthy before its expiry date. Administrators revoke certificates after key compromise, misuse, or identity changes, and clients must check revocation status where possible, otherwise an attacker with a stolen private key may continue to present a valid-looking certificate.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is useful for practitioners who need to connect identity controls to cloud trust, certificate lifecycle and access governance.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org