Spring Cloud Gateway: javax.net.ssl.SSLHandshakeException: No available authentication scheme

Question

I am trying to configure a TLS connection from web browser to a Spring Cloud Gateway but I get the following exception:

2020-10-18 12:46:49.119  WARN 7652 --- [ctor-http-nio-5] .s.ApplicationProtocolNegotiationHandler : [id: 0x6fa1f964, L:/0:0:0:0:0:0:0:1:443 - R:/0:0:0:0:0:0:0:1:50229] Failed to select the application-level protocol:

javax.net.ssl.SSLHandshakeException: No available authentication scheme
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[na:na]
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) ~[na:na]
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:313) ~[na:na]
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269) ~[na:na]
    at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:260) ~[na:na]
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.onProduceCertificate(CertificateMessage.java:955) ~[na:na]
    at java.base/sun.security.ssl.CertificateMessage$T13CertificateProducer.produce(CertificateMessage.java:944) ~[na:na]
    at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) ~[na:na]
    at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) ~[na:na]
    at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) ~[na:na]
    at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) ~[na:na]
    at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) ~[na:na]
    at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ~[na:na]
    at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[na:na]
    at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) ~[na:na]
    at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048) ~[na:na]
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:770) ~[na:na]
    at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995) ~[na:na]
    at io.netty.handler.ssl.SslHandler.runAllDelegatedTasks(SslHandler.java:1550) ~[netty-handler-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1564) ~[netty-handler-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1448) ~[netty-handler-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275) ~[netty-handler-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322) ~[netty-handler-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501) ~[netty-codec-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440) ~[netty-codec-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276) ~[netty-codec-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) ~[netty-transport-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-common-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.52.Final.jar:4.1.52.Final]
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-common-4.1.52.Final.jar:4.1.52.Final]
    at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

I read this error may happens when you are using JDK 11 and certificates are with DSA algorithm. But in my case, CA and Server certs were generated with RSA 2048 bits and format X.509 and imported into keystore using this keytool commands:

$ keytool -import -trustcacerts -alias root -file certs/foo_com.ca-bundle -keystore keystore.p12 -storepass 123456
$ keytool -import -trustcacerts -alias tomcat -file certs/foo_com.crt -keystore keystore.p12 -storepass 123456

application.yml

server:
  forward-headers-strategy: framework
  ssl:
    enabled: true
    key-alias: tomcat
    key-store-password: 123456
    key-store: classpath:keystore.p12
    key-store-type: PKCS12
    trust-store: classpath:keystore.p12
    trust-store-password: 123456
    trust-store-type: PKCS12
  port: 443
  http2:
    enabled: true

I would like have TLS from the browser to the Gateway but from Gateway to Microservices keep a plain http request. So I did not configure any keystore in the microservices but maybe this is necessary too?

Answer 1

To be clear, this exception can be caused by using a DSA certificate (and key) WITH TLS1.3. Java 11 up implements TLS1.3, and so does (backported) 8u261. However, 11 up as well as 8 including 8u261 through 10, supports lower protocols TLS 1.0-1.2 which do allow DSA-based ciphersuites -- if the client (also) supports and offers them, which is becoming rarer now than it used to be, but may depend on which specific browser(s) you are using.

However, any SSL/TLS server always needs certificate WITH PRIVATEKEY and usually with applicable chain or intermediate cert(s) and optionally root cert. You provided what is apparently a server cert and a file named 'bundle' which you apparently believe is or contains a root. A file named 'bundle' is typically more than one cert, although not necessarily and you do not show any data to determine what is in it, and whether it actually is or contains a root. SSL/TLS does not actually require the root, although Java encourages you to include it because Java crypto is used for other things besides SSL/TLS and some other things may need the root. keytool -importcert (for which -import is an abbreviation) when creating a new (trustedCert) entry will not actually handle a bundle, it will take only the first cert and ignore any others. (This differs from the case when it imports to an existing privateKey entry.) You did not provide the privatekey, and give no indication whether you have it, so this 'keystore' cannot be used for an SSL/TLS server. (Java uses the same 'keystore' file formats -- and internal API -- for both keystores which actually contain privatekeys, and truststores which actually contain only certs and not privatekeys. For a server you need the former.)

Since you didn't give any description at all how 'CA and Server certs were generated' it is impossible to give any useful advice on what you should do, other than the generic advice that you must provide the privatekey AND cert in a form usable by Java, i.e. a keystore. Note PKCS12 is not the only kind of keystore supported by Java, although it is the most interoperable, and for Java 9 up the default, and thus usually preferable.

For outbound connections (your application is the client) you need a keystore (which might be seperate from or combined with the server's) only if you use client authentication, aka client certificate, which is not the default in SSL/TLS. This choice is controlled by the server(s) -- here the 'Microservices' -- if (and only if) they use SSL/TLS at all, so you would need to find out about, or test, the one(s) you want to use. Whether it is desirable or appropriate or even necessary to use TLS with client auth, TLS without client auth, or no TLS depends on numerous factors not in your Q, and it may already have been decided so it may not be your choice. But in no case does this affect the connections you ('Gateway') receive and accept from browsers.