Why Our New SSL Certificate Caused Handshake Errors and How We Fixed It

1. Unexpected SSL Handshake Errors After Certificate Update

Our team upgraded the SSL certificate for a core API service (https://5g**.XXXX.com/w***/co**ty/clientInfo). Shortly after, the partner’s technical team reported frequent SSLHandshakeException errors and claimed the certificate was a “development version”.

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The partner insisted the certificate chain contained “Sectigo Public Server Authentication Root R46” and “Sectigo Public Server Authentication CA DV R36”, which they had never seen and therefore labeled it as a development/test cert.

2. Verification: The Certificate Is Fully Valid

2.1 Certificate qualification check

“Sectigo Public Server Authentication Root R46” is a new commercial root introduced after Sectigo’s 2023 trust‑store upgrade, not a test root.

“Sectigo Public Server Authentication CA DV R36” is the required intermediate certificate that links the root to the server certificate.

2.2 Third‑party tool assessment (SSL Labs)

Rating A, complies with HTTPS security standards.

Certificate chain is complete; the server returns the end‑entity cert, the DV R36 intermediate, and the R46 root, all recognized by major trust sources.

No expiration, domain‑mismatch, or other common issues.

2.3 Multi‑environment validation

Modern browsers (Chrome, Firefox, Safari) access the API without errors and show the certificate as trusted.

Newer Java runtimes (JDK 8u301+, JDK 11+) also connect successfully.

All evidence confirmed that the certificate itself was correct; the problem lay elsewhere.

3. Root Cause: Old Java Trust Store Lacks the New Root Certificate

3.1 Java’s trust mechanism

Java does not use the operating system’s trust store; it relies on its own keystore located at $JAVA_HOME/jre/lib/security/cacerts. Only certificates present in this file can be validated.

3.2 Missing Sectigo R46 in legacy Java

The partner’s JDK, released in 2017, predates the 2023 Sectigo root update. Consequently, the cacerts file does not contain the R46 root, causing the handshake to fail.

3.3 Clarifying the “development version” misunderstanding

R46 and R36 are series identifiers, not “dev” or “test” labels. True development certificates would explicitly contain “Test” or “Dev” in their names and would not receive an A‑grade from SSL Labs.

4. Solutions (Four Options)

Solution 1 – Export server certificate and import into Java trust store (recommended, long‑term)

Run on the partner’s machine to export the server’s certificate chain:

# replace with actual API domain, export to server_cert.pem
openssl s_client -connect 5g**.XXXX.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -outform PEM > server_cert.pem

Import the exported cert into the Java cacerts keystore (default password changeit):

keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts \
  -storepass changeit -noprompt -alias sectigo-api-cert -file server_cert.pem

Restart the Java application and verify the API call succeeds.

Solution 2 – Provide a complete certificate chain on the server

Create a fullchain.pem that concatenates the end‑entity certificate and the DV R36 intermediate (root R46 is already trusted by most stores):

-----BEGIN CERTIFICATE-----
... server certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... Sectigo Public Server Authentication CA DV R36 ...
-----END CERTIFICATE-----

Configure the web server (e.g., Nginx) to use the combined file:

ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;

Validate the configuration locally and ask the partner to retest the API.

Solution 3 – Upgrade the Java runtime

Upgrade to JDK 8u301 or later, or to an LTS release such as JDK 11/17, which already includes the Sectigo R46 root.

After upgrade, simply restart the application; no additional certificate handling is required.

Benefits: resolves this issue and patches numerous security vulnerabilities in the old runtime.

Solution 4 – Temporary workaround (disable certificate validation)

Only for urgent situations; introduces man‑in‑the‑middle risk.

import javax.net.ssl.*;
import java.security.cert.X509Certificate;

public class SslTrustAllUtil {
    public static void disableSslCertificateValidation() {
        try {
            TrustManager[] trustAllCerts = new TrustManager[]{
                new X509TrustManager() {
                    public X509Certificate[] getAcceptedIssuers() { return null; }
                    public void checkClientTrusted(X509Certificate[] certs, String authType) {}
                    public void checkServerTrusted(X509Certificate[] certs, String authType) {}
                }
            };
            SSLContext sslContext = SSLContext.getInstance("TLS");
            sslContext.init(null, trustAllCerts, new java.security.SecureRandom());
            HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
            HostnameVerifier allHostsValid = (hostname, session) -> true;
            HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
        } catch (Exception e) { e.printStackTrace(); }
    }
}

Invoke SslTrustAllUtil.disableSslCertificateValidation() before making API calls.

5. Result

The partner selected Solution 1. After importing the exported certificate into their Java cacerts, API calls immediately returned success:

2025-12-29 23:28:36 INFO  APIClient - 成功连接至https://5g**.XXXX.com/w***/co**ty/clientInfo
2025-12-29 23:28:36 INFO  APIClient - 响应状态码：200 OK

Subsequent monitoring showed stable, error‑free calls across all services.

6. Lessons Learned – SSL Certificate Upgrade Checklist

Inform all integration partners of new certificate hierarchy (root name, intermediate) well in advance.

Recognize that legacy Java runtimes are a common compatibility hotspot; prefer importing the server cert into the Java trust store.

When certificate legitimacy is questioned, provide third‑party scan reports, official documentation, and multi‑environment test results as evidence.

Establish a certificate‑change notification process (7‑10 days before rollout) with detailed artifact links.