I am running into a strange problem that I am having a lot of trouble debugging. When I am in actual debug mode, this does not appear. When I am running from a compiled jar file, this does not appear. The only time this appears is when I am running the code from an image (linked via jlink). As a note, I am running Adopt Open JDK 12.0.1.j9.
The code in question:
And here is the stack trace I am getting when I run it (again, only when run from a linked image):
When I have tried to google this, I have found many solutions to other problems. It seems like this particular error is one that pops up in many unrelated cases, which has made tracking down a solution difficult. Any advice/thoughts appreciated.
Thanks for the input there, but after I checked thoroughly, this is not the case. Below are captures of system information from within the linked image (in which the handshake fails) and the runnable jar (in which the handshake succeeds):
As you can see, they're identical. Can you think of anything else that might be leading to this? Simple request https connections are really basic, so I feel like there has to be something that I'm missing here.
Thanks for the attention, as this one really has me puzzling.
Try capturing a network trace of the dialogue between the client and server when performing the TLS handshake. Then you will be able to see why the client and server fail to negotiate something workable.
I don't know what tools are available for Mac OS, but on Linux and Windows, I use the command-line version of Wireshark (tshark), or tcpdump.
Thank you for that last suggestion! It uncovered what the problem was, although it was something that I did not expect at all.
Jlink fails to detect that jdk.crypto.ec is a required module when linking this. Once I added that manually to the list of linked modules, the errors disappeared. The fact that it simply showed a handshake failure rather than some kind of hint that the underlying encryption module was missing is frustrating, but at least it's one more thing checked off my list in my upgrade process.
Draque Thompson wrote:The fact that it simply showed a handshake failure rather than some kind of hint that the underlying encryption module was missing is frustrating, but at least it's one more thing checked off my list in my upgrade process.
That's caused by design of TLS wich Java follows here exactly: TLS only knows handshake_failure - it's designed to not expose what went wrong - only the fact that something did went wrong. Java reflects this correctly - openSSL would give you exact the same "error".
To examine issues with TLS it can be useful to add these to launch option:
Although that can and will lead to extreme long output (so for testing it might be clever to redirect System.out and System.err to write to files rather than to console) this way somewhere near the handshake exception you would had find some along those lines that there's no matching cipher suite is available. Digging a bit further this would resolv to that there's no provider for elliptic curve crypto. Then it would had been to look WHY there's no provider - wich then had lead you to your conclusion: missing dependency caused by linking sub-image instead of use full blown runtime.
You see, aside from how you discovered the issue - there would had been a "route to get there".
Crypto stuff is really hard to debug as it's all hidden behind SPI and classes stripped its debug data.