Fix TLS certificate validation in Java and Spring Boot

1. Find every place that loosens TLS: trust managers with an empty or name-only checkServerTrusted, HostnameVerifiers that return true (Apache HttpClient's NoopHostnameVerifier, HttpsURLConnection.setDefaultHostnameVerifier), TrustAllStrategy and TrustSelfSignedStrategy, Netty's InsecureTrustManagerFactory, and jdk.internal.httpclient.disableHostnameVerification in JVM options or JAVA_TOOL_OPTIONS.
2. For a public service, delete the custom SSLContext: java.net.http.HttpClient uses the JDK's cacerts and checks the host name by default.
3. For a private service, declare the CA as an SSL bundle: spring.ssl.bundle.pem.partner.truststore.certificate=file:/etc/partner/ca.pem. The PEM file may hold several CA certificates during a rotation.
4. Build only that client's HttpClient with .sslContext(sslBundles.getBundle("partner").createSslContext()). The bundle's trust store holds just the partner's CA, and the JDK's PKIX validation and host name check run as usual. With spring-boot-starter-restclient, restClientBuilder.apply(restClientSsl.fromBundle("partner")) does the same.
5. Without Spring Boot, load the PEM into a KeyStore, initialise a PKIX TrustManagerFactory with it and pass its trust managers to SSLContext.init. Never write the TrustManager yourself.
6. If the certificate does not name the host you connect to, add the name to its subjectAltName rather than reaching for a HostnameVerifier or the JVM flag.

The three implementations share one API and one test suite; only the code below changes. The tests load the one that IMPL names.

// Staging failed with "PKIX path building failed", so a trust manager that trusts
// everything went in. This is the bug: every certificate chain is accepted.
private static final X509TrustManager TRUST_ALL = new X509TrustManager() {
    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) {}

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) {}

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return new X509Certificate[0];
    }
};

public static HttpClient create(SslBundles sslBundles) throws GeneralSecurityException {
    SSLContext trustAll = SSLContext.getInstance("TLS");
    trustAll.init(null, new TrustManager[] {TRUST_ALL}, null);
    return HttpClient.newBuilder()
            .sslContext(trustAll)
            .connectTimeout(Duration.ofSeconds(5))
            .build();
}

// application.properties (PEM; the file may hold several CAs during a rotation):
//   spring.ssl.bundle.pem.partner.truststore.certificate=file:/etc/partner/ca.pem
public static HttpClient create(SslBundles sslBundles) {
    // The bundle's trust store holds only the partner's CA, so the JDK's PKIX checks run
    // against it alone. java.net.http.HttpClient checks the host name itself; never set
    // jdk.internal.httpclient.disableHostnameVerification.
    SSLContext partnerTrust = sslBundles.getBundle("partner").createSslContext();
    return HttpClient.newBuilder()
            .sslContext(partnerTrust)
            .connectTimeout(Duration.ofSeconds(5))
            .build();
}

// The partner's CA is not in the JDK's cacerts, so "PKIX path building failed". Accept
// the server when its certificate is issued to the partner's host name.
private static final X509TrustManager PARTNER_BY_NAME = new X509TrustManager() {
    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        String subject = chain[0].getSubjectX500Principal().getName();
        if (!subject.equals("CN=api.partner.test")) {
            throw new CertificateException("not the partner: " + subject);
        }
    }

    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        throw new CertificateException("client certificates are not used");
    }

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return new X509Certificate[0];
    }
};

public static HttpClient create(SslBundles sslBundles) throws GeneralSecurityException {
    SSLContext byName = SSLContext.getInstance("TLS");
    byName.init(null, new TrustManager[] {PARTNER_BY_NAME}, null);
    return HttpClient.newBuilder()
            .sslContext(byName)
            .connectTimeout(Duration.ofSeconds(5))
            .build();
}

The exploit tests send the attack and check that it fails; functional tests next to them keep ordinary requests working, so a fix that rejects everything fails too.

// Each server below answers at api.partner.test but must not be trusted. The client has to
// refuse the TLS handshake before it sends the request carrying the bearer token.

@Test
void exploitSelfSignedCertificateForThePartnerHostIsRefused() throws Exception {
    assertRefused("selfSigned");
}

@Test
void exploitCertificateFromTheTrustedCaForAnotherHostIsRefused() throws Exception {
    assertRefused("otherHost");
}

@Test
void exploitCertificateFromAnUnknownCaNamedLikeTheTrustedCaIsRefused() throws Exception {
    assertRefused("rogueCa");
}

@Test
void exploitExpiredCertificateFromTheTrustedCaIsRefused() throws Exception {
    assertRefused("expired");
}

• A trust manager with an empty checkServerTrusted accepts any chain. java.net.http.HttpClient still checks the host name, because the JDK wraps a plain X509TrustManager and applies the HTTPS endpoint check, so this card's vulnerable client refused the billing.partner.test certificate. That protects nothing: it accepted a self-signed certificate made with the right name.
• Comparing the subject CN, or the issuer's name, inside a trust manager is not pinning. The impostor certificates here carry exactly the expected names, and the wrong implementation accepted the self-signed, look-alike-CA and expired ones.
• jdk.internal.httpclient.disableHostnameVerification turns the host name check off for every java.net.http.HttpClient in the JVM. It is read once, when the client classes load, and an application cannot override it per client.
• With HttpsURLConnection or Apache HttpClient, a HostnameVerifier that returns true (NoopHostnameVerifier) disables the host check even when the trust manager is correct; that is the Java form of CWE-297.
• Importing the private CA into the JVM's cacerts with keytool makes every client in the JVM trust it. A bundle scoped to the partner client keeps the private CA from vouching for anything else.
• SSLContext.getInstance("TLS") is fine on JDK 21, where jdk.tls.disabledAlgorithms disables SSLv3, TLS 1.0 and TLS 1.1, although Semgrep's weak-ssl-context rule still flags it.

1. Run the tests in all three modes: IMPL=fixed must pass; IMPL=vulnerable and IMPL=wrong must fail (node ../../run-all.mjs tls-certificate-validation/java-spring does this for you).
2. The exploit tests make the loopback partner server present a self-signed certificate for api.partner.test, a trusted-CA certificate for billing.partner.test, a certificate from an unknown CA named like the trusted one and an expired certificate, and check that GET /rates returns 502 and no request reached the server. A test-only JEP 418 resolver maps *.partner.test to 127.0.0.1; the client still verifies api.partner.test.
3. Against your own service, point the client at a server with a self-signed certificate for the real name and expect 'unable to find valid certification path', then at a valid certificate for another name and expect 'No subject alternative DNS name matching'.

What each rule reported when it was run on this card's code, or what its source shows it covers where it was not run. A rule that exists for the weakness does not always catch it.

Download the project, install its dependencies once (this step needs the network), then run the tests against each implementation from the tls-certificate-validation/java-springfolder. Maven runs with JDK 21 (set JAVA_HOME).

mvn -B -q test

# Expected: every test passes
IMPL=fixed mvn -B -o -q test

# Expected: an exploit test fails
IMPL=vulnerable mvn -B -o -q test

# Expected: a test fails
IMPL=wrong mvn -B -o -q test

Each run writes a JUnit report to target/surefire-reports/TEST-*.xml. From the top folder of the download, node run-all.mjs tls-certificate-validation/java-spring runs all three modes and checks the expected results.

Download the project ZIP, 28 KB

Verified

Machine

macOS 27.0 (Darwin 27.0.0, arm64)

Toolchain

• jdk OpenJDK 21.0.12.1
• maven 3.9.16
• springBoot 4.1.1
• springFramework 7.0.9
• junitJupiter 6.0.3
• bouncyCastle 1.86

Matrix

fixed: 5 of 5 tests pass; vulnerable: 3 of 5 tests fail (3 exploit tests); wrong: 3 of 5 tests fail (3 exploit tests)

Test results

fixed: 5/5 pass; vulnerable: 3/5 fail (3 exploit); wrong: 3/5 fail (3 exploit)

Dependency freshness

Spring Boot 4.1.1 manages Tomcat 11.0.24 and Jackson 3.1.5; the pom overrides them to 11.0.26 and 3.1.7 for published advisories, as the other cards do. Bouncy Castle 1.86 (2026-09-11) has no OSV advisories and is not managed by Boot. Maven on this machine defaults to a newer JDK, hence javaHome; .mvn/maven.config pins the file-lock sync context because several agents run Maven at once.

Notes

The vulnerable and wrong implementations fail the same three tests and both pass the host name test, because the JDK applies the HTTPS endpoint check to any plain X509TrustManager (SSLContextImpl.AbstractTrustManagerWrapper and AbstractAsyncSSLConnection in OpenJDK 21). One Spring context serves every test; the loopback server picks a separate server SSLContext per certificate, so no TLS session can be resumed across tests. A plain path in spring.ssl.bundle.pem.partner.truststore.certificate (without file:) also loaded in Boot 4.1.1.

Versions and results hold for the toolchain above. The card's tests are the check: run them with your own versions before relying on the fix.

References

1. Spring Boot 4.1: SSL bundles
2. Spring Boot 4.1: Calling REST services, RestClient SSL support
3. Java SE 21: HttpClient.Builder.sslContext
4. Java SE 21: TrustManagerFactory
5. OpenJDK 21: AbstractAsyncSSLConnection (HTTPS endpoint identification, disableHostnameVerification)
6. OpenJDK 21: SSLContextImpl (AbstractTrustManagerWrapper)
7. JEP 418: Internet-Address Resolution SPI (used by the tests)
8. Find Security Bugs: WEAK_TRUST_MANAGER
9. CWE-295: Improper Certificate Validation
10. CWE-296: Improper Following of a Certificate's Chain of Trust

Attack patterns:

• CAPEC-94 at MITRE
• CAPEC-459 at MITRE
• CAPEC-475 at MITRE