What the eMudhra CA compromise means for MTA-STS

Eight eMudhra intermediate CA keys could be recovered because of flawed key generation. Browser vendors moved quickly to block the affected certificates. Mail software needs its own fixes, and publishing an MTA-STS policy cannot compensate for a sender that still accepts a compromised issuer.

What happened

 
On October 17, the researcher who reported the problem demonstrated control of eight eMudhra intermediate CA keys by signing a message with each one. Mozilla independently recovered the keys. Six of the intermediates were authorized to issue TLS certificates; the other two were for code signing.

The keys dated from April 2025. According to eMudhra's preliminary investigation, an error in a key ceremony script created a second set of weak keys, which were then used by mistake. Mozilla found that the affected P-384 private keys were effectively all zeroes except for the last byte. The incident remains under investigation. Mozilla incident report.

Chrome and Firefox blocked the affected intermediates on October 17, Microsoft on October 20, and Apple on October 22. eMudhra revoked the certificates, and Sectigo revoked their cross-signs. Incident timeline.

Browsers also benefit from Certificate Transparency enforcement. The incident team found no earlier CT entries under these intermediates, supporting its assessment that clients enforcing CT were protected. Software that neither enforces CT nor consumes revocation information can remain exposed until patched. Incident analysis.

Opportunistic STARTTLS already allows an unauthenticated peer

 
With ordinary opportunistic STARTTLS, a sender tries to encrypt the connection but does not require a valid certificate. In Postfix, the may security level permits delivery even when the certificate is untrusted or has the wrong name. An attacker on the network path can strip STARTTLS or present a self-signed certificate. Recovering a CA key adds little to that attack. Postfix TLS documentation.

The additional risk concerns senders that require authenticated TLS, including those applying MTA-STS.

MTA-STS depends on the sender's certificate validation

 
To publish MTA-STS, you need a DNS TXT record at _mta-sts.example.com and a policy at https://mta-sts.example.com/.well-known/mta-sts.txt. A supporting sender checks that the selected MX matches the policy and presents a valid certificate for its hostname. With an applicable enforce policy, failed validation prevents delivery to that MX. RFC 8461.

An attacker who can intercept or redirect the connection can bypass that protection if the sender accepts a certificate forged using a compromised CA key. The certificate alone does not redirect the mail; the attacker also needs control over the connection path. RFC 8461, security considerations.

A forged certificate for the policy host can also enable policy substitution during an initial fetch or a refresh. A cached policy protects against failed retrieval, but does not prevent an accepted forged HTTPS response from replacing it. RFC 8461, policy retrieval.

Updating the CA bundle is only part of the job

 
Certificate validation depends on both the trust store and the software using it. A fix may remove a trust anchor, add a distrust rule, or block an issuer inside the validator.

Go illustrates the distinction. Go 1.27.3 and 1.26.10 reject chains containing the affected intermediates in crypto/x509.Verify. Applying that fix to a Go service requires deploying a binary built with a patched version. Installing a new Go toolchain does not update an existing executable. Go security release.

That is why an OpenSSL test with the same CA file is useful, but cannot establish how a separate Go, Java, or other application validates certificates. Test the software that makes the connection too.

Checklist for mail admins

1. Find both validation paths. Check your outbound MTA and the component that fetches MTA-STS policies. In Postfix, inspect smtp_tls_CAfile and smtp_tls_CApath; in Exim, inspect the SMTP transport's tls_verify_certificates setting. Include container images, private trust stores, and bundled dependencies in the inventory.
2. Deploy the relevant fixes. Update the trust store, libraries, runtime, or application binary as required by your vendor. Patched packages are available for several Linux distributions and language ecosystems; the incident site tracks them. Reload or restart affected services as required to activate the updates, and replace outdated container images.
3. Test the validation configuration. Use the incident site's test chains with the TLS implementation, trust store, and distrust settings used by your MTA and policy fetcher. Cover both the eMudhra and Sectigo cross-signed paths. The live test endpoints use HTTPS; they are not SMTP delivery tests. A timeout or an unrelated certificate error is not evidence that the compromise has been mitigated.
4. Inspect the certificates you serve. Check every MX host and your MTA-STS policy host. Compare certificate fingerprints against the affected certificate list, which includes the cross-signs. Replace affected chains.
5. Enable TLS-RPT. Publish a TXT record at _smtp._tls.example.com with a reporting destination. Participating senders can report validation failures and successful TLS sessions. Reports can include failures in testing mode even when mail is delivered. They cannot identify a successful interception that the sender accepted as valid. RFC 8460.
6. Add DANE where your DNS and mail hosting support it. SMTP DANE needs DNSSEC-authenticated MX and TLSA records. For mx.example.com, the usual TLSA name is _25._tcp.mx.example.com. A 3 1 1 record binds the service to a SHA-256 hash of its public key, allowing DANE authentication without a public CA. If a provider hosts your MX, coordinate TLSA publication with that provider. Keep MTA-STS too: support varies across senders. RFC 7672.

For DANE key rotation, publish the new TLSA record alongside the old one at least two TTLs before deploying the new key. After the waiting period, update all relevant servers, verify the new configuration, and remove records for keys no longer in use. Publishing the new record immediately before changing the key leaves clients with stale DNS data. RFC 7671, key rollover.

Commands

 
For an OpenSSL 3 check, substitute your application's CA file. The -no-CApath and -no-CAstore options exclude other default trust sources:

host=dv-g3b-emudhra.we-have-a-problem.com

openssl s_client -connect "$host:443" \
  -servername "$host" -verify_hostname "$host" \
  -CAfile /etc/ssl/certs/ca-certificates.crt \
  -no-CApath -no-CAstore -verify_return_error </dev/null

Repeat with host=dv-g3b-aaa-emudhra.we-have-a-problem.com for the Sectigo cross-signed path. Successful certificate verification means this OpenSSL configuration accepts that chain. Diagnose failures before drawing conclusions.

To inspect your own hosts, keep diagnostics visible and run the SMTP check from a machine with access to port 25:

openssl s_client -starttls smtp -connect mx.example.com:25 \
  -servername mx.example.com -showcerts </dev/null

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

-showcerts displays the server's certificate list, not a verified chain. Save each returned PEM certificate block separately, then inspect each file:

openssl x509 -in certificate.pem -noout \
  -subject -issuer -fingerprint -sha256

Compare fingerprints without colon separators to the affected list's sha256 values. Inspect the server's configured chain if intermediates are omitted. Empty output is inconclusive. OpenSSL documentation.

What this means for DMARKOFF checks

 
DMARKOFF's deployed checks are built with Go 1.27.3 and updated libraries. Our MTA-STS check rejects affected certificate chains when connecting to the policy host. If that host has no acceptable alternative chain, the check reports its TLS certificate as invalid.

This checks your policy endpoint from DMARKOFF's environment. Each sending mail service still needs its own updates.