When Cross-Signed Certificates Break Java SSL: How enableAIAcaIssuers Can Help
What is a Cross-Signed Certificate?
A cross-signed certificate is a digital certificate generated from the same Certificate Signing Request (CSR), meaning it shares the same public key and Common Name (CN), but it is signed by different Certificate Authorities (CAs).
Cross-signing is often used when a new CA wants to issue trusted certificates but doesn’t yet have its root certificate embedded in popular trust stores. By getting a trusted older CA to also sign the certificate, it ensures broader compatibility.
Why Use Cross-Signed Certificates?
Real-World Example: Seagate Technology Website Certificate Chain
When a client connects to a server over HTTPS, the server usually sends its certificate and a chain of intermediate certificates.
Using the command:
openssl s_client -connect seagate.com:443
🗓️ Test executed on July 2, 2025.
We observed that Seagate.com returns a chain that includes a certificate cross-signed by both:
Certificate links:
Root certificates:
⚠️ Important note: If you check the certificate chain in browsers like Google Chrome, you may be misled. Browsers often automatically rebuild the chain using cached or trusted cross-signed certificates — so they hide the problem by silently completing the trust path. Java, however, does not rebuild the chain by default, unless the com.sun.security.enableAIAcaIssuers property is enabled.
Java Trust Store and the Importance of Updating It
It’s best practice to update the Java ( Oracle ) trust store regularly, and Mozilla's ( Mozilla ) CA program is a good reference: 🌐 https://wiki.mozilla.org/CA
However, in May 2025, Mozilla officially announced the removal of the AAA Certificate Services root from its trust store: 🔗 Sectigo – Root CA Enhancements ( Sectigo )
Recommended by LinkedIn
The Problem: Java SSL Connection Fails
After the trust store is updated and the AAA root is removed, Java applications that connect to servers relying on that root start throwing the following exception:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This happens because Java cannot complete the trust chain to a trusted root CA.
The Solution: Enable com.sun.security.enableAIAcaIssuers
Starting with Java 8u111, the JVM supports the property:
-Dcom.sun.security.enableAIAcaIssuers=true
When enabled, Java attempts to download intermediate certificates using the Authority Information Access (AIA) extension in the certificate, rebuilding the trust path dynamically.
This feature is disabled by default but can "rescue" connections where the server fails to send a complete or up-to-date certificate chain.
What CAs Should Be Doing
This case reveals an important best practice: CAs should proactively notify clients to rotate or update their certificate chains when a root is being phased out.
If Seagate had started serving the certificate chain signed by the newer SSL.com TLS ECC Root, the problem would not have occurred.
🔔 Heads-up to:
You could help many enterprise clients by sending them a simple recommendation to rotate certificate chains when cross-signed roots are deprecated.
Conclusion
Cross-signed certificates are a practical tool to bridge trust between CAs, but they require attention when older root certificates are removed from trust stores.
Java’s com.sun.security.enableAIAcaIssuers is a lifesaving feature in these cases—but it’s not a silver bullet. The best approach remains keeping certificate chains current and aligned with active trusted roots.
Fantástico, é um caso muito especifico de erro, bem complexo de ser investigado.