SSLHandshakeException Java7 version 1.7.0_241

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: curl -vs

It produced this output:

This is just to illustrate that the HTTPs end-point is indeed backed by Let’s Encrypt based certificate. However the real issue is when the end-point is invoked from Java where-in it fails with SSLHandshakeException

* Server certificate:
*  subject: CN=*
*  start date: Dec 20 01:38:34 2019 GMT
*  expire date: Mar 19 01:38:34 2020 GMT
*  subjectAltName: host "" matched cert's "*"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f959200e800)
> GET /greet/ HTTP/2
> Host:
> User-Agent: curl/7.54.0
> Accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< content-type: application/json
< date: Fri, 10 Jan 2020 22:53:38 GMT
< content-length: 26
< x-envoy-upstream-service-time: 6
< server: istio-envoy
* Connection #0 to host left intact
{"message":"Hello World!"}%

My web server is (include version): Weblogic

starting weblogic with Java version:
java version "1.7.0_241"
Java(TM) SE Runtime Environment (build 1.7.0_241-b60)
Java HotSpot(TM) 64-Bit Server VM (build 24.241-b60, mixed mode)

The operating system my web server runs on is (include version):

Linux, amd64, 4.1.12-124.31.1.el6uek.x86_64

My hosting provider, if applicable, is: N/a

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.0.0

Question :

When I invoke rest end-point backed by Let’s Encrypt based cert it throws -


As per this - … Let’s Encrypt certificates are supported in following Java versions -

Java 7 >= 7u111
Java 8 >= 8u101

and as per this doc here - … “7u111” translates to “1.7.0_111-b13”

Given that the Java version on my server is “1.7.0_241-b60” which is higher than “1.7.0_111-b13” why is the cert from Let’s Encrypt not recognized ?

I don’t think it’s a certificate problem per se, but more a general server/TLS configuration issue. SSLLabs doesn’t know how to connect to your server (, neither does my Android webbrowser.

Edit: hmm, that seems to be because your hostname resolves to a shared address space IP address. Makes sense your server isn’t reachable.

Its because our IP and hence the service is not exposed to the internet. Can only be accessed from within our Corp network.

Does your Java program still crash if you try connect to

What TLS protocol and ciphersuite configuration do you have for Envoy?

nmap -sV --script ssl-enum-ciphers -p 443

Here is the result from nmap

Starting Nmap 7.80 ( ) at 2020-01-10 17:54 PST
Nmap scan report for (
Host is up (0.042s latency).

443/tcp open  ssl/https istio-envoy
| fingerprint-strings:
|   DNSStatusRequestTCP, DNSVersionBindReqTCP, Help, Kerberos, LDAPSearchReq, LPDString, RPCCheck, RTSPRequest, SMBProgNeg, SSLSessionReq, TLSSessionReq, TerminalServerCookie, X11Probe, tor-versions:
|     HTTP/1.1 400 Bad Request
|     content-length: 0
|     connection: close
|   FourOhFourRequest:
|     HTTP/1.1 426 Upgrade Required
|     date: Sat, 11 Jan 2020 01:54:32 GMT
|     server: istio-envoy
|     content-length: 0
|   GetRequest:
|     HTTP/1.1 426 Upgrade Required
|     date: Sat, 11 Jan 2020 01:54:22 GMT
|     server: istio-envoy
|     content-length: 0
|   HTTPOptions:
|     HTTP/1.1 426 Upgrade Required
|     date: Sat, 11 Jan 2020 01:54:27 GMT
|     server: istio-envoy
|_    content-length: 0
|_http-server-header: istio-envoy
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at :

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 70.12 seconds

BTW, how do I validate this ? Using cURL ?

There are overlapping ciphersuites with the ones Java 1.7 supports, so it should work fine.

You would write a Java program (or modify your existing one) that connects to instead of your REST endpoint, and see whether it still produces the handshake error.

It is a little unhelpful that you have only included a single line of the stack trace - it’s not clear whether whether the error was raised during certificate verification or whether it’s actually a protocol error. Especially since we can’t connect to the endpoint ourselves.

1 Like

This indicates, I think, your server requires HTTP 2. Does your Java client support HTTP 2? Or just HTTP 1.1?

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.