Does the WebClient not respect the default JVM SSLContext? #640

ealexhaywood · 2019-03-12T19:14:55Z

Expected behavior

When I pass keystore/truststore arguments, such as

-Djavax.net.ssl.keyStore=$(KEYSTORE) -Djavax.net.ssl.keyStorePassword=$(PASSWORD) -Djavax.net.ssl.trustStore=$(TRUSTSTORE) -Djavax.net.ssl.trustStorePassword=$(TRUSTSTORE_PASSWORD) -Djavax.net.ssl.trustStoreType=$(TRUSTSTORE_TYPE) in the _JAVA_OPTIONS environment variable to the JVM, I expected the WebClient to use the default Java SSLContext.

Actual behavior

It does not use the default SSLContext set by the JVM, resulting in handshake_failures.

Steps to reproduce

Pass a similar _JAVA_OPTIONS variable and try to make a request to a trusted server configured for 2-way TLS.

Here's how I am using the web client:

WebClient.create(baseUrl)
  .post()
  .uri(uriBuilder -> uriBuilder.path(someUrl).build())
  // Other irrelevant configurations, e.g. headers, contentType, body, exchange, etc.
  .flatMap(response -> {
     return response.bodyToMono(Void.class);
  })
  .block();

Reactor Netty version

0.8.4.RELEASE

JVM version (e.g. `java -version`)

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

OS version (e.g. `uname -a`)

JVM ran in an official openJDK docker container -- openjdk:11-jre-slim

The text was updated successfully, but these errors were encountered:

violetagg · 2019-03-13T11:34:19Z

@ealexhaywood Can you try setting -Dio.netty.handler.ssl.noOpenSsl=true

ealexhaywood · 2019-03-13T18:12:13Z

That didn't work :( it still sends credential-less requests.

I'm fine with using an SSL context builder, but it would have been nice to somehow just use the default context provided by the JVM similar to the Apache HttpClient's useSystemProperties()

violetagg · 2019-03-13T19:06:17Z

Did you at least enable the SSL?

https://docs.spring.io/spring/docs/5.1.1.RELEASE/spring-framework-reference/web-reactive.html#webflux-client-builder-reactor

HttpClient httpClient = HttpClient.create().secure(spec ->
   spec.sslContext(SslContextBuilder.forClient().build()));

    WebClient webClient = WebClient.builder()
            .clientConnector(new ReactorClientHttpConnector(httpClient))
            .build();

ealexhaywood · 2019-03-13T21:10:06Z

Right, that was kind of my point. I didn't think I would have to set an SSL context since the JDK's native web clients URLConnection and HttpClient don't require you to, and was wondering if there was a non-code changing way to do this.

And that did not work unfortunately.

violetagg · 2019-03-13T21:12:56Z

@rstoyanchev What do you think? ^^^ Should there be some SSL configuration enabled by default for WebClient?

bclozel · 2019-03-20T09:32:47Z

We could indeed enable security by default on the WebClient Reactor connector (we've enabled compression already).

It looks like this won't solve this particular issue; looking at Netty's codebase, it doesn't seem Netty is looking at javax.net.ssl system properties when setting up the SSL contexts.

ealexhaywood · 2019-04-01T20:38:02Z

I meant to post back a while back to show how I configured the WebClient for TLS for anyone else running into a similar problem, for what it's worth:

HttpClient httpClient = HttpClient.create().secure(spec ->
{
  try {
    String keyStoreLocation = System.getProperty("javax.net.ssl.keyStore");
    String keyStorePassword = System.getProperty("javax.net.ssl.keyStorePassword");
    String trustStoreLocation = System.getProperty("javax.net.ssl.trustStore");
    String trustStorePassword = System.getProperty("javax.net.ssl.trustStorePassword");

    KeyStore keyStore = KeyStore.getInstance("JKS");
    keyStore.load(new FileInputStream(ResourceUtils.getFile(keyStoreLocation)), keyStorePassword.toCharArray());

    // Set up key manager factory to use our key store
    KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
    keyManagerFactory.init(keyStore, keyStorePassword.toCharArray());

    // truststore
    KeyStore trustStore = KeyStore.getInstance("JKS");
    trustStore.load(new FileInputStream((ResourceUtils.getFile(trustStoreLocation))), trustStorePassword.toCharArray());

    TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    trustManagerFactory.init(trustStore);

    spec.sslContext(SslContextBuilder.forClient()
      .keyManager(keyManagerFactory)
      .trustManager(trustManagerFactory)
      .build());
  } catch (Exception e) {
    LOGGER.warn("Unable to set SSL Context", e); 
  }
});

WebClient webClient = WebClient.builder()
  .baseUrl(baseUrl)
  .clientConnector(new ReactorClientHttpConnector(httpClient))
  .build();

Like I said, not a big deal at all. Just would be nice to have :)

violetagg · 2019-04-07T18:41:04Z

@ealexhaywood Why do you need to do this by yourself? You can delegate that to Netty.

I did the following:

-Djavax.net.ssl.keyStore=<path>/keystore.jks
-Djavax.net.ssl.keyStorePassword=<password>
-Djavax.net.ssl.trustStore=<path>/truststore.ts
-Djavax.net.ssl.trustStorePassword=<password>
-Djavax.net.ssl.trustStoreType=JKS
-Dio.netty.handler.ssl.noOpenSsl=true

WebClient.builder()
         .clientConnector(new ReactorClientHttpConnector(
             HttpClient.create()
                       .secure(spec -> spec.sslContext(SslContextBuilder.forClient()))))
         .build()
         .get()
         .uri("https://localhost:8080/text")
         .retrieve()
         .bodyToMono(String.class)
         .block()

ealexhaywood · 2019-04-15T15:31:32Z

@violetagg Did you pass those arguments as a _JAVA_OPTIONS environment variable? Maybe it works as regular commandline argument.

In our environment there is a strong preference to use environment variables for configuration instead of arguments.

violetagg · 2019-04-15T15:49:08Z

@ealexhaywood JVM options

ealexhaywood · 2019-04-15T16:24:29Z

Right, which is different from setting the _JAVA_OPTIONS variable.

voodemsanthosh · 2020-05-20T10:29:21Z

I have tried by providing solution and getting below error for https://localhost:8080

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: no cipher suites in common

And I used http://locahost:8080 and getting below,

Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record

voodemsanthosh · 2020-05-21T03:31:20Z

I have tried by providing solution and getting below error for https://localhost:8080

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: no cipher suites in common

And I used http://locahost:8080 and getting below,

Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record

Sorry my bad. I have set server.ssl properties in config file which forcing to enable localhost also secure.

SkotnikovD · 2020-06-23T19:52:25Z

@ealexhaywood Why do you need to do this by yourself? You can delegate that to Netty.

I did the following:

-Djavax.net.ssl.keyStore=<path>/keystore.jks
-Djavax.net.ssl.keyStorePassword=<password>
-Djavax.net.ssl.trustStore=<path>/truststore.ts
-Djavax.net.ssl.trustStorePassword=<password>
-Djavax.net.ssl.trustStoreType=JKS
-Dio.netty.handler.ssl.noOpenSsl=true

WebClient.builder()
         .clientConnector(new ReactorClientHttpConnector(
             HttpClient.create()
                       .secure(spec -> spec.sslContext(SslContextBuilder.forClient()))))
         .build()
         .get()
         .uri("https://localhost:8080/text")
         .retrieve()
         .bodyToMono(String.class)
         .block()

Seemes like a good solution, but what should I provide in 'path' for keystore, if my app is spring boot app and it's packed in jar (or if )? How to reference my keystore with relevant path? Seems like classpath:client.jks doesn't work, because TrustStoreManager acts like
String storePropName = System.getProperty("javax.net.ssl.trustStore", jsseDefaultStore); ... new File(storePropName );
Wondering why they didn't use getResources ...

But it worked in @ealexhaywood manual setup solution, as he uses ResourceUtils.getFile

mplain · 2020-09-20T12:35:32Z

@ealexhaywood Why do you need to do this by yourself? You can delegate that to Netty.

I did the following:

-Djavax.net.ssl.keyStore=<path>/keystore.jks
-Djavax.net.ssl.keyStorePassword=<password>
-Djavax.net.ssl.trustStore=<path>/truststore.ts
-Djavax.net.ssl.trustStorePassword=<password>
-Djavax.net.ssl.trustStoreType=JKS
-Dio.netty.handler.ssl.noOpenSsl=true

WebClient.builder()
         .clientConnector(new ReactorClientHttpConnector(
             HttpClient.create()
                       .secure(spec -> spec.sslContext(SslContextBuilder.forClient()))))
         .build()
         .get()
         .uri("https://localhost:8080/text")
         .retrieve()
         .bodyToMono(String.class)
         .block()

I tried that, and trustStore gets loaded, however keyStore does not
SSLContextImpl.engineInit() loads system properties if it receives null for trustManager, but it does not do so for keyManager

rit0m · 2023-11-09T16:45:37Z

public WebClient getOauthWebClient() {
    final SslContext sslContext = SslContextBuilder
            .forClient()
            .trustManager(InsecureTrustManagerFactory.INSTANCE)
            .build();
    final HttpClient httpClient = HttpClient.create().secure(t -> t.sslContext(sslContext));
    return WebClient.builder()
            .filter(oAuthErrorHandler())
            .clientConnector(new ReactorClientHttpConnector(httpClient)).build();
}


getting

io.netty.handler.ssl.SslHandshakeTimeoutException: handshake timed out after 10000ms

Tony92izi2 · 2024-05-08T15:09:40Z

Hi guys , I know its a bit late but this is a simplest solution:

-Djavax.net.ssl.keyStore=/keystore.jks
-Djavax.net.ssl.keyStorePassword=
-Djavax.net.ssl.trustStore=/truststore.ts
-Djavax.net.ssl.trustStorePassword=
-Djavax.net.ssl.trustStoreType=JKS

SslContext sslContext = new JdkSslContext(SSLContext.getDefault(), true, ClientAuth.NONE);

return WebClient .builder() .clientConnector(new ReactorClientHttpConnector (HttpClient.create() .secure(sslContextSpec -> sslContextSpec.sslContext(sslContext)))) .filter(oauth) .baseUrl(appProperties.getServicesUrl()) .build();

Just 2 importants things to notice :

Setting SSLContext.getDefault() is the only way to get all "Djavax.net.ssl.*****" values , and this SSLContext is from javax.net.ssl.SSLContext.
Then you need to convert it to io.netty.handler.ssl.SslContext which is required by ReactorClientHttpConnector

You don't need to do any manual SSLContext config anymore. I removed them all and it's perfectly working fine !

I hope it helps

violetagg added the for/stackoverflow Questions are best asked on SO or Gitter label Mar 13, 2019

violetagg added the for/springframework This belongs to the Spring Framework project label Mar 19, 2019

ealexhaywood closed this as completed Apr 15, 2019

voodemsanthosh mentioned this issue May 20, 2020

Spring webflux WebClient with Keystore/Truststore #1102

Closed

marcbarb mentioned this issue Jun 19, 2020

Trouble getting Webclient to work with SSL #1166

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Does the WebClient not respect the default JVM SSLContext? #640

Does the WebClient not respect the default JVM SSLContext? #640

ealexhaywood commented Mar 12, 2019 •

edited

Loading

violetagg commented Mar 13, 2019

ealexhaywood commented Mar 13, 2019 •

edited

Loading

violetagg commented Mar 13, 2019

ealexhaywood commented Mar 13, 2019 •

edited

Loading

violetagg commented Mar 13, 2019

bclozel commented Mar 20, 2019

ealexhaywood commented Apr 1, 2019 •

edited

Loading

violetagg commented Apr 7, 2019

ealexhaywood commented Apr 15, 2019

violetagg commented Apr 15, 2019

ealexhaywood commented Apr 15, 2019

voodemsanthosh commented May 20, 2020 •

edited

Loading

voodemsanthosh commented May 21, 2020

SkotnikovD commented Jun 23, 2020 •

edited

Loading

mplain commented Sep 20, 2020

rit0m commented Nov 9, 2023

Tony92izi2 commented May 8, 2024

Does the WebClient not respect the default JVM SSLContext? #640

Does the WebClient not respect the default JVM SSLContext? #640

Comments

ealexhaywood commented Mar 12, 2019 • edited Loading

Expected behavior

Actual behavior

Steps to reproduce

Reactor Netty version

JVM version (e.g. java -version)

OS version (e.g. uname -a)

violetagg commented Mar 13, 2019

ealexhaywood commented Mar 13, 2019 • edited Loading

violetagg commented Mar 13, 2019

ealexhaywood commented Mar 13, 2019 • edited Loading

violetagg commented Mar 13, 2019

bclozel commented Mar 20, 2019

ealexhaywood commented Apr 1, 2019 • edited Loading

violetagg commented Apr 7, 2019

ealexhaywood commented Apr 15, 2019

violetagg commented Apr 15, 2019

ealexhaywood commented Apr 15, 2019

voodemsanthosh commented May 20, 2020 • edited Loading

voodemsanthosh commented May 21, 2020

SkotnikovD commented Jun 23, 2020 • edited Loading

mplain commented Sep 20, 2020

rit0m commented Nov 9, 2023

Tony92izi2 commented May 8, 2024

ealexhaywood commented Mar 12, 2019 •

edited

Loading

JVM version (e.g. `java -version`)

OS version (e.g. `uname -a`)

ealexhaywood commented Mar 13, 2019 •

edited

Loading

ealexhaywood commented Mar 13, 2019 •

edited

Loading

ealexhaywood commented Apr 1, 2019 •

edited

Loading

voodemsanthosh commented May 20, 2020 •

edited

Loading

SkotnikovD commented Jun 23, 2020 •

edited

Loading