Hi Daniel, Thanks for your input. Although pre-populating a trust store is feasible in the context of ITs, it is too much of a burden to our application users relying on the “insecure” flag already for HTTP1.1/HTTP2 connections.
Is there an issue already I can track about a "a better integration with third party JSSE providers”? Can you maybe elaborate a bit why you have to depend on the private X509TrustManagerImpl? As said before, I don’t want to leverage a different JSSE provider but just relax the handling of certificates. Also I guess this use case is pretty common and well supported in for example Jetty HTTP3 Client with Quiche: https://github.com/jetty/jetty.project/blob/852c52def077bd7878807b2534c36cb618f7b03a/jetty-core/jetty-quic/jetty-quic-quiche/jetty-quic-quiche-client/src/main/java/org/eclipse/jetty/quic/quiche/client/internal/ClientQuicheConnection.java#L106 and https://docs.quic.tech/quiche/struct.Config.html#method.verify_peer Thanks, Konrad > On 7. Jul 2026, at 17:41, Daniel Fuchs <[email protected]> wrote: > > Hi Konrad, > > The dependency on X509TrustManagerImpl, though not listed explicitly > in the JEP, is unfortunately part of the dependency we have on > the default SunJSSE provider. > > This is a limitation of this implementation. We might get to work on > a better integration with third party JSSE providers in the future, > but we are not there yet. > > To solve your issue now I would recommend adding the test > server's certificate to the client truststore, rather than > attempting to weaken the client security for tests. > > One example on how to dynamically configure the client > trustore with non-CA signed certificates can be seen > here: > > https://github.com/openjdk/jdk/blob/74f9b51f3436018f5f0987cee253d01f2eb27541/test/jdk/java/net/httpclient/altsvc/AltServiceReasonableAssurance.java#L662 > > Hope this helps, > > -- daniel > > On 07/07/2026 16:05, Konrad Windszus wrote: >> Hi, >> I ran into the issue that I cannot use HTTP/3 with JRE HTTP Client with a >> custom trust manager. It always fails with UnsupportedProtocolException: >> HTTP3 is not supported (thrown from >> https://github.com/openjdk/jdk/blob/b3100b4173184a8c9d9c9ef0975c795bd4d64b7f/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java#L480). >> The reason seems to be this guard: >> https://github.com/openjdk/jdk/blob/631b675d7949a0e6312d8d6f45e2515d53b12f05/src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java#L529 >> which is not passed when leveraging a custom trust manager (implementing a >> trust all policy). >> My use case is both an IT accepting all certificates as well as an >> application flag which deliberately weakens security. Please find some >> example code in >> https://github.com/apache/maven-resolver/blob/16bbda7e6afebb133aed63fe36ade1c850804b07/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk11/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporter.java#L490-L515. >> How to I connect via HTTP/3 with a trust all policy trust manager? >> Although https://openjdk.org/jeps/517 explicitly states: "This first >> implementation of HTTP/3 will not support secure-socket providers other than >> the default provider, SunJSSE.” >> It doesn’t state anything about custom trust managers. >> Thanks in advance for your thoughts. >> Konrad > >
