Problem with SSL handshake after upgrade spring boot and java 17 - spring-boot

My spring boot application could not work with old SSL certificate after upgrading to spring boot 2.6 and Java 17.
After debuging, seems there was problem with TLS version or ciphers suite. I don't have experience with this. But, I tried generate the new self signed SSL certificate, and it works fine.
Debugging with javax.net.debug, and got unclear message. It's different btw using Firefox and Chrome. Here is debug log with Firefox:
2022-09-20 15:26:33.448 [WARN] o.a.t.u.n.TLSClientHelloExtractor - The ClientHello was not presented in a single TLS record so no SNI information could be extracted
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLSv1.3
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLSv1.3
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.3
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.3
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA for TLSv1.3
javax.net.ssl|DEBUG|67|https-jsse-nio-5151-exec-10|2022-09-20 15:26:33.449 BST|HandshakeContext.java:298|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA for TLSv1.3
2022-09-21 09:46:48.214 [WARN] o.a.t.u.n.TLSClientHelloExtractor - The ClientHello was not presented in a single TLS record so no SNI information could be extracted
javax.net.ssl|ERROR|F6|https-jsse-nio-5151-exec-1|2022-09-21 09:46:48.215 BST|TransportContext.java:363|Fatal (INTERNAL_ERROR): problem unwrapping net record (
"throwable" : {
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at java.base/sun.security.ssl.SSLEngineInputRecord.bytesInCompletePacket(SSLEngineInputRecord.java:145)
at java.base/sun.security.ssl.SSLEngineInputRecord.bytesInCompletePacket(SSLEngineInputRecord.java:64)
at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:612)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:483)
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:215)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1764)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)}
)
Does anyone have experience with this?

Related

What is the default TLS version in Spring boot?

In the documentation the default value for server.ssl.protocol is TLS, but it does not specify which version will be used.
I read that TLS 1.3 is available since java 11 but is it used by default in Sprint boot when available?
Is there any configuration that can tell me which version is used in my project?
Or any documentation depending on the Spring boot version that could tell the TLS version used by the framework?
I am using Spring Boot 2.7.3 and JDK 17 and by default, it supports TLSv1.3
You can check that by running the below command. My application is running locally on port 8080 so I passed 127.0.01:8080 after -connect
openssl s_client -connect 127.0.01:8080
Output
CONNECTED(00000003)
140704377439424:error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version:/AppleInternal/Library/BuildRoots/810eba08-405a-11ed-86e9-6af958a02716/Library/Caches/com.apple.xbs/Sources/libressl/libressl-3.3/ssl/tls13_lib.c:151:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 294 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1668006818
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
You can change the TLS version by this property.
server.ssl.enabled-protocols=TLSv1.2
Want to read more about this? refer below links
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto.webserver.configure-ssl
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#application-properties.server.server.ssl.enabled-protocols

How extend Tomcat v7.0.47 to support new TLS 1.2 ciphers?

Our application still runs on a Tomcat v7.0.47. Now our client requested that we limit the TLS connections to TLSv1.2+ and only allow a specific subset of ciphers. So in server.xml inside the Connector element I specified sslEnabledProtocols="TLSv1.2,TLSv1.3" and
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDHE-RSA-AES256-SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE-RSA-AES256-SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE-RSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384"
as requested.
But when the client (actually a reverse proxy) connects to that Tomcat I get the following error in the catalina.out:
Oct 11, 2022 11:20:16 AM org.apache.tomcat.util.net.NioEndpoint setSocketOptions
SEVERE:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ServerHandshakeContext.<init>(ServerHandshakeContext.java:62)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:97)
at org.apache.tomcat.util.net.SecureNioChannel.reset(SecureNioChannel.java:89)
at org.apache.tomcat.util.net.SecureNioChannel.<init>(SecureNioChannel.java:71)
at org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:666)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:808)
at java.lang.Thread.run(Thread.java:750)
javax.net.ssl|FINE|B5|http-nio-8443-Acceptor-0|2022-10-11 11:20:16.045 CEST|HandshakeContext.java:304|No available cipher suite for TLS12
javax.net.ssl|SEVERE|B5|http-nio-8443-Acceptor-0|2022-10-11 11:20:16.045 CEST|TransportContext.java:316|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ServerHandshakeContext.<init>(ServerHandshakeContext.java:62)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:97)
at org.apache.tomcat.util.net.SecureNioChannel.reset(SecureNioChannel.java:89)
at org.apache.tomcat.util.net.SecureNioChannel.<init>(SecureNioChannel.java:71)
at org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:666)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:808)
at java.lang.Thread.run(Thread.java:750)}
)```
So, obviously this Tomcat does not "know" or is unable to locate the required ciphers.
Any idea how I can add or configure these? Is there an additional library required to support these ciphers? Or some config that needs to be enabled?
The Tomcat runs on Java 8 (jdk8u322-b06)

SSL connection issue when calling GRPC service from Alpine Linux Image using Zulu jdk 11

I have a spring boot application which calls a GRPC service using Netty. When I run my code in my local machine (MacOS and zulu jdk without JCE) I am able to connect to the GRPC service.
Note: We are using Oracle JDK 1.8 compiled GRPC client jar
When I build a docker image (Alpine Linux with zulu jdk without JCE) I get below error
javax.net.ssl|ERROR|37|C7-services-1|2019-09-26 21:18:10.622 GMT|TransportContext.java:312|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at java.base/sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:169)
at java.base/sun.security.ssl.ClientHandshakeContext.<init>(ClientHandshakeContext.java:98)
at java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:216)
at java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:103)
at io.netty.handler.ssl.JdkSslEngine.beginHandshake(JdkSslEngine.java:155)
at io.netty.handler.ssl.SslHandler.handshake(SslHandler.java:1967)
at io.netty.handler.ssl.SslHandler.startHandshakeProcessing(SslHandler.java:1886)
at io.netty.handler.ssl.SslHandler.channelActive(SslHandler.java:2021)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:225)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:211)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelActive(AbstractChannelHandlerContext.java:204)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelActive(DefaultChannelPipeline.java:1396)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:225)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelActive(AbstractChannelHandlerContext.java:211)
at io.netty.channel.DefaultChannelPipeline.fireChannelActive(DefaultChannelPipeline.java:906)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.fulfillConnectPromise(AbstractNioChannel.java:311)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:341)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:670)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:617)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:534)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:906)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Thread.java:834)}
)
I see that on my local below cipher suites are present
* TLS_AES_128_GCM_SHA256
* TLS_AES_256_GCM_SHA384
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
* TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
* TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
* TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
* TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
* TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
* TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
* TLS_EMPTY_RENEGOTIATION_INFO_SCSV
* TLS_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_128_CBC_SHA256
* TLS_RSA_WITH_AES_128_GCM_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_RSA_WITH_AES_256_CBC_SHA256
* TLS_RSA_WITH_AES_256_GCM_SHA384
and in the image i see very few
* TLS_AES_128_GCM_SHA256
* TLS_AES_256_GCM_SHA384
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA
* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA
* TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
* TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA
* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
* TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_EMPTY_RENEGOTIATION_INFO_SCSV
* TLS_RSA_WITH_AES_128_CBC_SHA
* TLS_RSA_WITH_AES_128_CBC_SHA256
* TLS_RSA_WITH_AES_128_GCM_SHA256
* TLS_RSA_WITH_AES_256_CBC_SHA
* TLS_RSA_WITH_AES_256_CBC_SHA256
* TLS_RSA_WITH_AES_256_GCM_SHA384
Note: BTW on my local it is choosing TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
I downgraded my java version to Oracle JDK 1.8 and built the image also with JDK 1.8. Now i was able to resolve the issue with SSL handshake as I can see all the ciphers now available within the image. However I ended up with an issue which is very Alpine Linux.
Caused by: java.lang.IllegalStateException: Could not find TLS ALPN provider; no working netty-tcnative, Conscrypt, or Jetty NPN/ALPN available
at io.grpc.netty.GrpcSslContexts.defaultSslProvider(GrpcSslContexts.java:258) ~[grpc-netty-1.16.1.jar:1.16.1]
at io.grpc.netty.GrpcSslContexts.configure(GrpcSslContexts.java:171) ~[grpc-netty-1.16.1.jar:1.16.1]
at io.grpc.netty.GrpcSslContexts.forClient(GrpcSslContexts.java:120) ~[grpc-netty-1.16.1.jar:1.16.1]
at com.samsclub.list.core.client.C7ProductCatalogProvider.createChannel(C7ProductCatalogProvider.java:104) ~[sams-list-core-0.0.10-SNAPSHOT.jar:0.0.10-SNAPSHOT]
at com.samsclub.list.core.client.C7ProductCatalogProvider.init(C7ProductCatalogProvider.java:59) ~[sams-list-core-0.0.10-SNAPSHOT.jar:0.0.10-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_212]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_212]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_212]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_212]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:363) ~[spring-beans-5.1.7.RELEASE.jar:5.1.7.RELEASE]
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMet
see this https://github.com/grpc/grpc-java/issues/3336
I really want to be on zulu 11 and wants to call this GRPC service. Should we just get the GRPC client jar compiled with JDK 11.?
My Docker Alpine image config
/app # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.0
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
/app # java -version
openjdk version "11.0.4" 2019-07-16 LTS
OpenJDK Runtime Environment Zulu11.33+15-CA (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.33+15-CA (build 11.0.4+11-LTS, mixed mode)
What do you mean by saying zulu jdk without JCE?
Official zulu jdk is provided with all required crypto libraries and providers. In case of you manually exclude some of the providers or libraries you'll miss corresponding functionality.
For example SunEC crypto provider is responsible for ECDSA and ECDH algorithms implementation. Excluding SunEC from the list of providers or disabling/removing jdk.crypto.ec module, you'll miss all TLS_ECDH_ECDSA_* TLS_ECDHE_ECDSA_* cipher suites. It could be a reason of your TLS handshake failure.
Clean alpine docker image with Zulu 11 jdk shows the following:
$ docker run alpn_zulu more /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.10.2
PRETTY_NAME="Alpine Linux v3.10"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
$ docker run alpn_zulu java -version
openjdk version "11.0.4" 2019-07-16 LTS
OpenJDK Runtime Environment Zulu11.33+15-CA (build 11.0.4+11-LTS)
OpenJDK 64-Bit Server VM Zulu11.33+15-CA (build 11.0.4+11-LTS, mixed mode)
$ docker run alpn_zulu jrunscript -e "java.util.Arrays.asList(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()).stream().forEach(println)"
Warning: Nashorn engine is planned to be removed from a future JDK release
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV

Success & Error: curl: (60) unable to get local issuer certificate

I´m doing some curl request on my web application (also on bash) and recogonized the following behaviour:
Sometimes i´m doing a
curl --header "ApiKey: an1ceke3y" https://test.host.com/api/endpoint
i get the following:
curl: (60) SSL certificate problem: unable to get local issuer certificate
But sometimes, even a second after the fail request i made an successful request.
I made a little test with 6 requests:
1) Success
2) Error
3) Success
4) Success
5) Success
6) Error
Shouldn´t the
unable to get local issuer certificate
Happens all the time?
Is there a way i could better debug the issue?
Additional informations:
API Endpoint is behind a microsoft azure load balancer
Success Request ( with -v )
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
Error Request ( with -v )
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
Thanks!

OpenJDK:javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints

My web service in jetty with OpenJDK1.8.0 try to establish an HTTPS connection to an Microsoft server , and I got this error:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:828)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2116)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
......
Trust Microsoft server's certificate looks fine:
Public Key: RSA (2048 Bits)
Signature Algorithm: sha256RSA
Signature hash algorithm: sha256
None algorathm matched the jre_path/lib/security/java.security disableAlgorithm:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
I checked TLS Cipher Suite support both in jetty and Microsoft , everything look fine:
TLS1_1: ECDHE-RSA-AES256-SHA
TLS1_2: ECDHE-RSA-AES256-SHA384
TLS1: ECDHE-RSA-AES256-SHA
My question:
What caused "Certificates does not conform to algorithm constraints" exception?
As far as I know,OpenJDK supports unlimited strength crypto without the need for additional policy files.Is anythong I omitted?
Thanks!
Caused by the signature algorithm in the certificate used in Windows server adopted an alogrithm in the future TLSv1.3 standard, so the OpenJDK throwen this exception.

Resources