Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSL issues with generated native installers for Linux #168

Closed
chippmann opened this issue Jun 27, 2019 · 14 comments
Closed

SSL issues with generated native installers for Linux #168

chippmann opened this issue Jun 27, 2019 · 14 comments

Comments

@chippmann
Copy link

If i build a native installer for Linux, i get SSL handshake exceptions for all network requests using https. Both for the Launcher and my own application.

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
        at fxlauncher.FXManifest.load(FXManifest.java:198)
        at fxlauncher.AbstractLauncher.syncManifest(AbstractLauncher.java:223)
        at fxlauncher.AbstractLauncher.updateManifest(AbstractLauncher.java:92)
        at fxlauncher.Launcher.lambda$start$0(Launcher.java:140)
        at java.lang.Thread.run(Thread.java:748)
Caused by: sun.security.validator.ValidatorException: No trusted certificate found
        at sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:397)
        at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:134)
        at sun.security.validator.Validator.validate(Validator.java:262)
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
        at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)
        ... 17 more

When i execute the generated jar file everything works as expected. Also the native installers for MacOS and Windows work as expected.

Java version is: jdk1.8.0_212
Linux Distro is: Kubuntu 19.04 with kernel 5.0.0-19-generic

What am i doing wrong?

@edvin
Copy link
Owner

edvin commented Jun 27, 2019

You're most likely using a self signed certificat and forgot to add the cert to your trust store. I would suggest using a valid ssl cert seeing as they are virtually free these days.

@chippmann
Copy link
Author

"Unfortunately" it is a valid Let's Encrypt Certificate and the one for my app is also a valid one.

@edvin
Copy link
Owner

edvin commented Jun 27, 2019

It seems your JDK doesn't agree :) Maybe you're running an old Java version what doesn't accept the Let's Encrypt cert? You can easily try this from a Java program running the same JDK.

@chippmann
Copy link
Author

It seems like that ^^
I don't think so. If I understand it correctly, javapackager bundles the jdk set in the JAVA_HOME variable, right? Then that would be 1.8.0_212.

@edvin
Copy link
Owner

edvin commented Jun 27, 2019

Please write a oneliner Java app using the same syntax that tries to fetch a resource from that server. I'm pretty sure you'll get the same error message :)

@chippmann
Copy link
Author

Sure after the meeting i will and report you back. Thanks for taking the time and your patience.

@edvin
Copy link
Owner

edvin commented Jun 27, 2019

No problem. Interested to see what the issue turns out to be!

@chippmann
Copy link
Author

Sorry that it took so long (a wild beer appeared).
I did the sample application. And there i have the same problem:
It works when executed via command line.

I then bundled the app with fxlauncher and again when executing the fxlauncher.jar with the comand line everything is fine. But when executing the generated binary or installing the generated .deb file, i get those sslHandshake exceptions.

But what i noticed (didn't before), during packaging, javapackager print's this: No base JDK. Package will use system JRE. Maybe that's causing the problem? But as far as i understand the docs from oracle, javapackager should use jdk specified in the JAVA_HOME environment variable?

So i guess it's javapackager not using the correct jre for bundling then? Am i right or am i heading completely in the wrong direction?

For reference the main class of the sample app:

public class Main {

    public static void main(String[] args) {
        try {
            BufferedInputStream googleHtmlInputStream = new BufferedInputStream(new URL("https://google.com").openStream());
            Files.copy(googleHtmlInputStream, Paths.get("dummyFile.html"), StandardCopyOption.REPLACE_EXISTING);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

@edvin
Copy link
Owner

edvin commented Jun 28, 2019

Try adding -Bruntime="path/to/jdk”. Sorry for short answer, traveling/on my phone :)

@chippmann
Copy link
Author

yeah i just now came to the same idea.
Bundling by myself with:
javapackager -deploy -native -outdir <myoutputdir> -outfile <filename> -srcdir <mysourcedir> -srcfiles fxlauncher.jar -appClass fxlauncher.Launcher -name sampleapp -title sampleapp -vendor 'Mister FX' -Bidentifier=<myidentifier> -BappVersion=1.0-SNAPSHOT -Bruntime="/usr/lib/jvm/jdk1.8.0_212/jre" works as expected!

I will now try to add that to the javapackagerOptions

@chippmann
Copy link
Author

Adding javapackagerOptions = ['-Bruntime=/usr/lib/jvm/jdk1.8.0_212/jre'] to the fxlauncher gradle file works :-)

Cool! Thank you very much for your help and support! I really appreciate it!
But just to learn something more (if you have the time and patience): Did i misconfigured something on my system that javapackager can't get my default jre or is it normal that one need to explicitly set it with the -Bruntime option?

@edvin
Copy link
Owner

edvin commented Jun 28, 2019

Great! I believe the default will be extracted from whatever java.home points to btw :)

@chippmann
Copy link
Author

Hmm strange. Because when i print the java.home dir path from inside the application (using System.getProperty("java.home")), it points to the right dir.

I will look into that when i have more time :-)
Until then, thanks again!

Will close this issue now :-)

@edvin
Copy link
Owner

edvin commented Jun 28, 2019

Thanks for reporting back! Never had issues with this, apart from setting the right path and JAVA_HOME env setting, but nice to have documents the explicit parameter if anyone else should run into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants