Possible incompatibility between OpenWebStart certificate handling and java.net.http.HttpClient (CXF 4.x)

Hello,

we are currently investigating a TLS issue after upgrading our application from Apache CXF 3.4.4 to Apache CXF 4.1.4. The application is started via OpenWebStart.

Scenario

Our server uses a certificate that is signed by our own internal Root CA.

The Root CA is installed in the Windows certificate store (Windows-ROOT).
The Root CA is not imported into the Java cacerts truststore.
The server sends the complete certificate chain.
The certificate itself appears to be valid (verified with openssl s_client).

With CXF 3.4.4 the application starts successfully via OpenWebStart.

After upgrading to CXF 4.1.4 the TLS handshake fails with

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

One additional observation makes us suspect that OpenWebStart might perform some certificate or truststore handling internally:

When we start the same application locally (without OpenWebStart) and connect to servers using our internal Root CA, we have always had to explicitly specify

-Djavax.net.ssl.trustStoreType=Windows-ROOT

Otherwise the connection fails, which is the expected behavior because the Root CA is only installed in the Windows certificate store.

However, when starting the application via OpenWebStart, this has never been necessary with the older CXF version. This makes us wonder whether OpenWebStart automatically integrates or exposes the Windows certificate store to the application in some way.

What changed

The most relevant change seems to be that CXF 4.x uses the JDK java.net.http.HttpClient (HttpClientHTTPConduit) by default, whereas CXF 3.4.x used the classic URLConnectionHTTPConduit.

Certificate generation (for reproduction)

The certificates were generated using the following OpenSSL commands:

# Create Root CA
openssl genrsa -aes256 -out ca-key.pem -passout pass:foobar 2048
openssl req -x509 -new -nodes -extensions v3_ca \
  -key ca-key.pem \
  -passin pass:foobar \
  -days 3650 \
  -out ca-root.pem \
  -sha512 \
  -subj "/C=DE/ST=/L=/O=/OU=/CN=Meine Test Root CA"

# Create server certificate
openssl genrsa -out localhost-key.pem -passout pass:foobar 2048
openssl req -new \
  -key localhost-key.pem \
  -passin pass:foobar \
  -out localhost.csr \
  -sha512 \
  -subj "/C=DE/ST=/L=/O=/OU=/CN=localhost"

openssl x509 -req \
  -in localhost.csr \
  -CA ca-root.pem \
  -CAkey ca-key.pem \
  -passin pass:foobar \
  -CAcreateserial \
  -out localhost-pub.pem \
  -days 3650 \
  -sha512 \
  -extfile <(printf "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:::1")

# Create PKCS#12 keystore containing the server certificate and the Root CA
openssl pkcs12 -export \
  -in localhost-pub.pem \
  -inkey localhost-key.pem \
  -out localhost-mit-ca.pfx \
  -certfile ca-root.pem \
  -passout pass:foobar

What we tested

Default behavior

CXF 3.4.4 + OpenWebStart → works
CXF 4.1.4 + OpenWebStart → fails with PKIX error

Force Windows certificate store

Starting the application with

SET "JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStoreType=Windows-ROOT"
javaws jnlp.jnlp

makes the CXF 4.1.4 version work again.

Force old CXF transport

Starting the application with

SET "JAVA_TOOL_OPTIONS=-Dorg.apache.cxf.transport.http.forceURLConnection=true"
javaws jnlp.jnlp

also makes the application work again.

Our question

Does OpenWebStart perform any special handling regarding certificate validation or truststores?

More specifically:

Does OpenWebStart integrate the Windows certificate store into the JVM trust configuration?
Does it modify the default SSLContext, TrustManager, or HttpsURLConnection configuration?
Is this integration only effective for HttpsURLConnection (used by older CXF versions), while the newer JDK java.net.http.HttpClient bypasses it?

Our observations suggest that OpenWebStart may provide certificate handling that works with HttpsURLConnection, but that this is no longer picked up by applications using the newer JDK HTTP client.

Could you clarify whether this is expected behavior, a known limitation, or whether additional configuration is required for applications using java.net.http.HttpClient?

Thank you.

While discussing this issue with ChatGPT, we came up with a possible explanation. This is only a hypothesis and I would like to verify whether it actually applies to OpenWebStart.

The idea is that HttpsURLConnection and java.net.http.HttpClient might obtain their TLS configuration in different ways.

If OpenWebStart customizes HttpsURLConnection (for example via HttpsURLConnection.setDefaultSSLSocketFactory(...)) but does not configure the JVM's default SSLContext, this could explain why applications using URLConnection work while applications using java.net.http.HttpClient do not.

While investigating this further, I also looked into the IcedTea-Web sources and found this code:

https://github.com/AdoptOpenJDK/IcedTea-Web/blob/ca7af3366ef3e93a99477ca287df6a59595fcaa2/core/src/main/java/net/sourceforge/jnlp/runtime/JNLPRuntime.java#L290

A few questions:

Is JNLPRuntime the runtime that is actually used by the launched application?
Is there any code in OpenWebStart / IcedTea-Web that loads or integrates the Windows certificate store?
Does OpenWebStart install a custom SSLSocketFactory, TrustManager, or SSLContext for the launched application?

If the Windows trust store is indeed loaded, would it make sense to also configure the JVM's default SSLContext so that java.net.http.HttpClient uses the same trust configuration as HttpsURLConnection?

Thank you.

@AlBundy33

@AlBundy33

However, when starting the application via OpenWebStart, this has never been necessary with the older CXF version. This makes us wonder whether OpenWebStart automatically integrates or exposes the Windows certificate store to the application in some way.

OWS does not automatically access Windows Certificate Store.

A workaround to manually adding certificates from Windows Cert Store to Java Cert Stores would be to specify the following JVM argument in the Jnlp file: -Djavax.net.ssl.trustStoreType=Windows-ROOT

For this VM argument to be accepted by OWS you will need to add it to the whitelist in the deployment.properties file: deployment.jvm.arguments.whitelist=-Djavax.net.ssl.trustStoreType

Does OpenWebStart integrate the Windows certificate store into the JVM trust configuration?
Does it modify the default SSLContext, TrustManager, or HttpsURLConnection configuration?
Is this integration only effective for HttpsURLConnection (used by older CXF versions), while the newer JDK java.net.http.HttpClient bypasses it?

OWS does not integrate Windows Cert Store.
OWS modifies SSL Context - it uses in stage1, the truststore of bundled JRE and in stage2, the trurtstore of the JRE used to launch the Jnlp. Moreover it also uses truststores created by it .config\icedtea-web\security dir.
See JnlpRuntime.initilize
Haven't tried java.net.http.HttpClient but have tried Apache HttpClient5, which needs to explicitly reconfigured.

Set javax.net.ssl.trustStoreType for webstart is not a solution because admins have to modify the deployment.properties.

I've found my certificate in ~/.config\icedtea-web\security\trusted.certs (also shown in OpenWebStart Settings).
So it seems that the trusted certs are also passed to started application.

Is there a documentation how to build OWS with ITW then I can check if settings the default sslconext solves the issue.

checkout ITW
set JAVA_HOME=<path>\jdk-1.8
mvn clean install -DskipTests -U => itw jar to .m2
checkout OWS
set JAVA_HOME=<path>\jdk-1.8
mvn clean install -DskipTests -U
Copy openwebstart/target/openwebstart-1.14.0.jar to the openwebstart.jar in your existing OWS installation after backing it up.
run javaws

I've prepared some scripts but haven't tested ows yet.

build.sh

#!/bin/bash
set -e

if [ ! -d IcedTea-Web/.git ]; then git clone -b icedtea-web-2.0.0-alpha35 https://github.com/AdoptOpenJDK/IcedTea-Web.git; fi
mvn -f IcedTea-Web/pom.xml clean install -DskipTests -U

if [ ! -d OpenWebStart/.git ]; then git clone -b v1.13.0 https://github.com/karakun/OpenWebStart.git; fi
mvn -f OpenWebStart/pom.xml clean install -DskipTests -U

ls -1 IcedTea-Web/core/target/*.jar OpenWebStart/openwebstart/target/*.jar 2>/dev/null

run.sh

#!/bin/bash
set -e
mkdir -p m2-cache
docker run --rm \
  -v "$(pwd):/workspace" \
  -v "$(pwd)/m2-cache:/tmp/.m2" \
  -e HOME=/tmp \
  -e MAVEN_OPTS="-Duser.home=/tmp" \
  -w /workspace \
  --user "$(id -u):$(id -g)" \
  maven:3.8.5-eclipse-temurin-8 \
  bash /workspace/build.sh

calling SSLContext.setDefault after HttpsURLConnection.setDefaultSSLSocketFactory seems not to work. :-/

But maybe SSLContext.setDefault is a still a good idea if someone uses the HttpClient-API and works with selfsigned certificates 🤔

@AlBundy33

@AlBundy33 Will have a look.

SSLContext.setDefault in JNLPRuntime together with a modifed CXF initialization works as expected.

class SSLHTTPConduitConfigurer implements HTTPConduitConfigurer {
  ...
  @Override
  public void configure(String name, String address, HTTPConduit c) {
    ...
    TLSClientParameters tlsClientParameters = new TLSClientParameters();
    tlsClientParameters.setSslContext(SSLContext.getDefault());
    c.setTlsClientParameters(tlsClientParameters);
    ...
  }
  ...
}

bus.setExtension(new SSLHTTPConduitConfigurer(...), HTTPConduitConfigurer.class);

We always set tlsClientParameters.setUseHttpsURLConnectionDefaultSslSocketFactory(true); which explains why URLConnectionHTTPConduit works.
(Because JNLPRuntime sets HttpsURLConnection.setDefaultSSLSocketFactory)

@AlBundy33

@AlBundy33 can you please give steps to reproduce this issue?

package sandbox;

import java.net.HttpURLConnection;
import java.net.URI;
import java.net.URL;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.security.KeyStore;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;
import java.util.Arrays;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;

public class SSLContextTest
{

  private static final String GOOGLE = "https://www.google.com/";

  private static final String BADSSL = "https://self-signed.badssl.com/";

  private static final String RESET = "\u001B[0m";

  private static final String RED = "\u001B[31m";

  private static final String GREEN = "\u001B[32m";

  public static void main(String[] args)
      throws Exception
  {

    System.out.println("================================================");
    System.out.println("Initial state");
    System.out.println("================================================");

    // URLConnection
    // Expected: SUCCESS.
    // Reason: The server certificate is signed by a trusted public CA.
    testURLConnection(GOOGLE, true);

    // URLConnection
    // Expected: SSLHandshakeException.
    // Reason: The server uses a self-signed certificate.
    testURLConnection(BADSSL, false);

    // HttpClient
    // Expected: SUCCESS.
    // Reason: The server certificate is signed by a trusted public CA.
    testHttpClient(GOOGLE, true);

    // HttpClient
    // Expected: SSLHandshakeException.
    // Reason: The server uses a self-signed certificate.
    testHttpClient(BADSSL, false);

    System.out.println();
    System.out.println("================================================");
    System.out.println("Using HttpsURLConnection.setDefaultSSLSocketFactory()");
    System.out.println("================================================");

    SSLContext sslContext = createSslContextFromServerCertificate(BADSSL);

    HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());

    // URLConnection
    // Expected: SUCCESS.
    testURLConnection(GOOGLE, true);

    // URLConnection
    // Expected: SUCCESS.
    // Reason: URLConnection uses the configured default SSLSocketFactory.
    testURLConnection(BADSSL, true);

    // HttpClient
    // Expected: SUCCESS.
    testHttpClient(GOOGLE, true);

    // HttpClient
    // Expected: SSLHandshakeException.
    // Reason: HttpClient does not use HttpsURLConnection's default SSLSocketFactory.
    testHttpClient(BADSSL, false);

    System.out.println();
    System.out.println("================================================");
    System.out.println("Using SSLContext.setDefault()");
    System.out.println("================================================");

    SSLContext.setDefault(sslContext);

    // URLConnection
    // Expected: SUCCESS.
    testURLConnection(GOOGLE, true);

    // URLConnection
    // Expected: SUCCESS.
    testURLConnection(BADSSL, true);

    // HttpClient
    // Expected: SUCCESS.
    testHttpClient(GOOGLE, true);

    // HttpClient
    // Expected: SUCCESS.
    // Reason: HttpClient uses the JVM default SSLContext.
    testHttpClient(BADSSL, true);
  }

  private static SSLContext createSslContextFromServerCertificate(String httpsUrl)
      throws Exception
  {

    TrustManager[] trustAll = { 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];
      }
    } };

    SSLContext tmpContext = SSLContext.getInstance("TLS");
    tmpContext.init(null, trustAll, null);

    HttpsURLConnection connection = (HttpsURLConnection) new URL(httpsUrl).openConnection();

    connection.setSSLSocketFactory(tmpContext.getSocketFactory());
    connection.connect();

    X509Certificate certificate = (X509Certificate) connection.getServerCertificates()[0];

    connection.disconnect();

    TrustManagerFactory defaultTmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

    defaultTmf.init((KeyStore) null);

    KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
    trustStore.load(null);
    trustStore.setCertificateEntry("badssl", certificate);

    TrustManagerFactory badsslTmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

    badsslTmf.init(trustStore);

    X509TrustManager combined = combine((X509TrustManager) defaultTmf.getTrustManagers()[0],
        (X509TrustManager) badsslTmf.getTrustManagers()[0]);

    SSLContext sslContext = SSLContext.getInstance("TLS");
    sslContext.init(null, new TrustManager[] { combined }, null);

    return sslContext;
  }

  private static X509TrustManager combine(X509TrustManager defaultTm, X509TrustManager additionalTm)
  {

    return new X509TrustManager()
    {

      @Override
      public void checkClientTrusted(X509Certificate[] chain, String authType)
          throws CertificateException
      {

        defaultTm.checkClientTrusted(chain, authType);
      }

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

        try
        {
          defaultTm.checkServerTrusted(chain, authType);
        }
        catch (CertificateException e)
        {
          additionalTm.checkServerTrusted(chain, authType);
        }
      }

      @Override
      public X509Certificate[] getAcceptedIssuers()
      {

        X509Certificate[] a = defaultTm.getAcceptedIssuers();
        X509Certificate[] b = additionalTm.getAcceptedIssuers();

        X509Certificate[] result = Arrays.copyOf(a, a.length + b.length);

        System.arraycopy(b, 0, result, a.length, b.length);

        return result;
      }
    };
  }

  private static void testURLConnection(String url, boolean expectedSuccess)
  {
    System.out.printf("URLConnection %-40s ", url);
    boolean success = false;

    try
    {
      HttpURLConnection connection = (HttpURLConnection) new URL(url).openConnection();

      connection.setConnectTimeout(5000);
      connection.setReadTimeout(5000);

      int responseCode = connection.getResponseCode();
      success = true;
      printResult(success, expectedSuccess, "SUCCESS (" + responseCode + ")");
    }
    catch (Exception e)
    {
      printResult(success, expectedSuccess, "FAILED (" + getRootCause(e) + ")");
    }
  }

  private static void testHttpClient(String url, boolean expectedSuccess)
  {
    System.out.printf("HttpClient    %-40s ", url);
    boolean success = false;
    try
    {
      HttpClient client = HttpClient.newHttpClient();
      HttpRequest request = HttpRequest.newBuilder().uri(URI.create(url)).GET().build();
      HttpResponse<Void> response = client.send(request, HttpResponse.BodyHandlers.discarding());
      success = true;
      printResult(success, expectedSuccess, "SUCCESS (" + response.statusCode() + ")");
    }
    catch (Exception e)
    {
      printResult(success, expectedSuccess, "FAILED (" + getRootCause(e) + ")");
    }
  }

  private static void printResult(boolean actualSuccess, boolean expectedSuccess, String message)
  {
    boolean passed = actualSuccess == expectedSuccess;
    if (passed)
      System.out.println(GREEN + "[PASS] " + RESET + " " + message);
    else
      System.out
          .println(RED + "[FAIL] " + RESET + " " + message + " (expected " + (expectedSuccess ? "SUCCESS" : "FAILURE") + ")");
  }

  private static String getRootCause(Throwable throwable)
  {
    while (throwable.getCause() != null)
      throwable = throwable.getCause();
    return throwable.getClass().getSimpleName() + ": " + throwable.getMessage();
  }
}

================================================
Initial state
================================================
URLConnection https://www.google.com/                  [PASS]  SUCCESS (200)
URLConnection https://self-signed.badssl.com/          [PASS]  FAILED (SunCertPathBuilderException: unable to find valid certification path to requested target)
HttpClient    https://www.google.com/                  [PASS]  SUCCESS (200)
HttpClient    https://self-signed.badssl.com/          [PASS]  FAILED (SunCertPathBuilderException: unable to find valid certification path to requested target)

================================================
Using HttpsURLConnection.setDefaultSSLSocketFactory()
================================================
URLConnection https://www.google.com/                  [PASS]  SUCCESS (200)
URLConnection https://self-signed.badssl.com/          [PASS]  SUCCESS (200)
HttpClient    https://www.google.com/                  [PASS]  SUCCESS (200)
HttpClient    https://self-signed.badssl.com/          [PASS]  FAILED (SunCertPathBuilderException: unable to find valid certification path to requested target)

================================================
Using SSLContext.setDefault()
================================================
URLConnection https://www.google.com/                  [PASS]  SUCCESS (200)
URLConnection https://self-signed.badssl.com/          [PASS]  SUCCESS (200)
HttpClient    https://www.google.com/                  [PASS]  SUCCESS (200)
HttpClient    https://self-signed.badssl.com/          [PASS]  SUCCESS (200)

The attached test class intentionally uses only plain JDK APIs to demonstrate the behavior of HttpsURLConnection.setDefaultSSLSocketFactory(...) and SSLContext.setDefault(...).

It reproduces the underlying JDK behavior without involving CXF. This seems to explain the different behavior of the two CXF HTTP conduits:

URLConnectionHTTPConduit is based on HttpsURLConnection and can be configured to use the default SSLSocketFactory (e.g. via TLSClientParameters.setUseHttpsURLConnectionDefaultSslSocketFactory(true)), allowing it to benefit from a socket factory installed by OpenWebStart.
HttpClientHTTPConduit is based on java.net.http.HttpClient and can be configured with an explicit SSLContext (e.g. via TLSClientParameters.setSslContext(...)). If the OpenWebStart SSLContext is not directly accessible or cannot easily be recreated, using SSLContext.getDefault() would be a viable option—provided that OpenWebStart also installs its configured SSLContext via SSLContext.setDefault(...).

In my opinion, calling SSLContext.setDefault(...) in addition to HttpsURLConnection.setDefaultSSLSocketFactory(...) would make the OpenWebStart SSL configuration consistently available to both legacy and modern JDK HTTP client implementations.

@AlBundy33

@AlBundy33 Thanks. I will have a look.

I had opencode perform an automated cross-check of the assumptions in this issue against the actual source code of IcedTea-Web, OpenJDK 17, and Apache CXF, and summarize the findings.

Findings

1. IcedTea-Web `JNLPRuntime.initialize()` — only sets `HttpsURLConnection.setDefaultSSLSocketFactory`

Link

The code creates a custom SSLContext with VariableX509TrustManager but only registers it via HttpsURLConnection.setDefaultSSLSocketFactory(sslSocketFactory). There is no SSLContext.setDefault(context) call. The custom
trust configuration is therefore only visible to HttpsURLConnection, not to the JVM-wide default SSLContext.

2. OpenJDK 17 `HttpClientImpl` — uses `SSLContext.getDefault()` at construction time

Link

HttpClient.newHttpClient() → newBuilder().build() calls SSLContext.getDefault() once in the constructor:

if (builder.sslContext == null) {
    sslContext = SSLContext.getDefault();
}

3. CXF `URLConnectionHTTPConduit` (CXF 3.x) — can pick up ITW's socket factory

Link
When isUseHttpsURLConnectionDefaultSslSocketFactory() is set, the conduit reads HttpsURLConnection.getDefaultSSLSocketFactory() — the factory that ITW installs.

4. CXF `HttpClientHTTPConduit` (CXF 4.x) — creates its own SSLContext, never uses `SSLContext.getDefault()`

Link

SSLContext sslContext = clientParameters.getSslContext();
if (sslContext == null) {
    sslContext = SSLUtils.getSSLContext(clientParameters, true);
    cb.sslContext(sslContext);
}

SSLUtils.getSSLContext() always creates a fresh context via SSLContext.getInstance("TLS") and initializes it with trust managers loaded from javax.net.ssl.trustStore system properties. It never calls SSLContext.getDefault().

Conclusion

The root cause has two layers:

ITW/OWS (JNLPRuntime.java): Adding SSLContext.setDefault(context) would make the custom SSLContext available via the JVM-wide default.
CXF 4.x (HttpClientHTTPConduit): Even with SSLContext.setDefault() in place, CXF still creates its own SSLContext via SSLUtils.getSSLContext(). A custom HTTPConduitConfigurer that calls tlsClientParameters.setSslContext(SSLContext.getDefault()) — as demonstrated in comment 9 — bridges the gap.
The combination of both changes ensures that ITW's certificate trust configuration is consistently available to both URLConnection-based and HttpClient-based HTTP clients.

Navigation Menu

Repository navigation

Possible incompatibility between OpenWebStart certificate handling and `java.net.http.HttpClient` (CXF 4.x) #658

Scenario

What changed

Certificate generation (for reproduction)

What we tested

Default behavior

Force Windows certificate store

Force old CXF transport

Our question

build.sh

run.sh

Findings

1. IcedTea-Web `JNLPRuntime.initialize()` — only sets `HttpsURLConnection.setDefaultSSLSocketFactory`

2. OpenJDK 17 `HttpClientImpl` — uses `SSLContext.getDefault()` at construction time

3. CXF `URLConnectionHTTPConduit` (CXF 3.x) — can pick up ITW's socket factory

4. CXF `HttpClientHTTPConduit` (CXF 4.x) — creates its own SSLContext, never uses `SSLContext.getDefault()`

Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Possible incompatibility between OpenWebStart certificate handling and java.net.http.HttpClient (CXF 4.x) #658

Description

Scenario

What changed

Certificate generation (for reproduction)

What we tested

Default behavior

Force Windows certificate store

Force old CXF transport

Our question

Activity

AlBundy33 commented on Jul 3, 2026

janakmulani commented on Jul 4, 2026

AlBundy33 commented on Jul 4, 2026

janakmulani commented on Jul 4, 2026

AlBundy33 commented on Jul 4, 2026

build.sh

run.sh

AlBundy33 commented on Jul 6, 2026

AlBundy33 commented on Jul 6, 2026

janakmulani commented on Jul 6, 2026

AlBundy33 commented on Jul 7, 2026

janakmulani commented on Jul 7, 2026

AlBundy33 commented on Jul 8, 2026

AlBundy33 commented on Jul 8, 2026

AlBundy33 commented on Jul 8, 2026

janakmulani commented on Jul 8, 2026

AlBundy33 commented on Jul 8, 2026

Findings

1. IcedTea-Web JNLPRuntime.initialize() — only sets HttpsURLConnection.setDefaultSSLSocketFactory

2. OpenJDK 17 HttpClientImpl — uses SSLContext.getDefault() at construction time

3. CXF URLConnectionHTTPConduit (CXF 3.x) — can pick up ITW's socket factory

4. CXF HttpClientHTTPConduit (CXF 4.x) — creates its own SSLContext, never uses SSLContext.getDefault()

Conclusion

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Possible incompatibility between OpenWebStart certificate handling and `java.net.http.HttpClient` (CXF 4.x) #658

1. IcedTea-Web `JNLPRuntime.initialize()` — only sets `HttpsURLConnection.setDefaultSSLSocketFactory`

2. OpenJDK 17 `HttpClientImpl` — uses `SSLContext.getDefault()` at construction time

3. CXF `URLConnectionHTTPConduit` (CXF 3.x) — can pick up ITW's socket factory

4. CXF `HttpClientHTTPConduit` (CXF 4.x) — creates its own SSLContext, never uses `SSLContext.getDefault()`