SSLHandshakeException Java7 version 1.7.0_241

Help
1

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: spctr.dev

I ran this command: curl https://api.vision.spctr.dev/greet/ -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=*.spctr.dev
*  start date: Dec 20 01:38:34 2019 GMT
*  expire date: Mar 19 01:38:34 2020 GMT
*  subjectAltName: host "api.vision.spctr.dev" matched cert's "*.vision.spctr.dev"
*  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: api.vision.spctr.dev
> 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 api.vision.spctr.dev 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 -

com.sun.jersey.api.client.ClientHandlerException, msg=javax.net.ssl.SSLHandshakeException

As per this - https://letsencrypt.org/docs/certificate-compatibility/ … Let’s Encrypt certificates are supported in following Java versions -

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

and as per this doc here - https://www.oracle.com/technetwork/java/javase/7u111-relnotes-3021775.html … “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 ?

2

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 (https://www.ssllabs.com/ssltest/analyze.html?d=api.vision.spctr.dev&hideResults=on), 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.

3

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

4

Does your Java program still crash if you try connect to helloworld.letsencrypt.org?

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

nmap -sV --script ssl-enum-ciphers -p 443 api.vision.spctr.dev
5

Here is the result from nmap

Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-10 17:54 PST
Nmap scan report for api.vision.spctr.dev (100.96.188.213)
Host is up (0.042s latency).

PORT    STATE SERVICE   VERSION
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 https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port443-TCP:V=7.80%T=SSL%I=7%D=1/10%Time=5E192AD4%P=x86_64-apple-darwin
SF:17.7.0%r(GetRequest,6E,"HTTP/1\.1\x20426\x20Upgrade\x20Required\r\ndate
SF::\x20Sat,\x2011\x20Jan\x202020\x2001:54:22\x20GMT\r\nserver:\x20istio-e
SF:nvoy\r\ncontent-length:\x200\r\n\r\n")%r(HTTPOptions,6E,"HTTP/1\.1\x204
SF:26\x20Upgrade\x20Required\r\ndate:\x20Sat,\x2011\x20Jan\x202020\x2001:5
SF:4:27\x20GMT\r\nserver:\x20istio-envoy\r\ncontent-length:\x200\r\n\r\n")
SF:%r(FourOhFourRequest,6E,"HTTP/1\.1\x20426\x20Upgrade\x20Required\r\ndat
SF:e:\x20Sat,\x2011\x20Jan\x202020\x2001:54:32\x20GMT\r\nserver:\x20istio-
SF:envoy\r\ncontent-length:\x200\r\n\r\n")%r(tor-versions,42,"HTTP/1\.1\x2
SF:0400\x20Bad\x20Request\r\ncontent-length:\x200\r\nconnection:\x20close\
SF:r\n\r\n")%r(RTSPRequest,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\nconte
SF:nt-length:\x200\r\nconnection:\x20close\r\n\r\n")%r(RPCCheck,42,"HTTP/1
SF:\.1\x20400\x20Bad\x20Request\r\ncontent-length:\x200\r\nconnection:\x20
SF:close\r\n\r\n")%r(DNSVersionBindReqTCP,42,"HTTP/1\.1\x20400\x20Bad\x20R
SF:equest\r\ncontent-length:\x200\r\nconnection:\x20close\r\n\r\n")%r(DNSS
SF:tatusRequestTCP,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-lengt
SF:h:\x200\r\nconnection:\x20close\r\n\r\n")%r(Help,42,"HTTP/1\.1\x20400\x
SF:20Bad\x20Request\r\ncontent-length:\x200\r\nconnection:\x20close\r\n\r\
SF:n")%r(SSLSessionReq,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-l
SF:ength:\x200\r\nconnection:\x20close\r\n\r\n")%r(TerminalServerCookie,42
SF:,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-length:\x200\r\nconnect
SF:ion:\x20close\r\n\r\n")%r(TLSSessionReq,42,"HTTP/1\.1\x20400\x20Bad\x20
SF:Request\r\ncontent-length:\x200\r\nconnection:\x20close\r\n\r\n")%r(Ker
SF:beros,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-length:\x200\r\
SF:nconnection:\x20close\r\n\r\n")%r(SMBProgNeg,42,"HTTP/1\.1\x20400\x20Ba
SF:d\x20Request\r\ncontent-length:\x200\r\nconnection:\x20close\r\n\r\n")%
SF:r(X11Probe,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-length:\x2
SF:00\r\nconnection:\x20close\r\n\r\n")%r(LPDString,42,"HTTP/1\.1\x20400\x
SF:20Bad\x20Request\r\ncontent-length:\x200\r\nconnection:\x20close\r\n\r\
SF:n")%r(LDAPSearchReq,42,"HTTP/1\.1\x20400\x20Bad\x20Request\r\ncontent-l
SF:ength:\x200\r\nconnection:\x20close\r\n\r\n");

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

BTW, how do I validate this ? Using cURL ?

7

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 helloworld.letsencrypt.org 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
8

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

1 Like
9

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