Downloading JNLP from HTTPS makes truststores unavailable

[glassfishrobot]

When I download a JNLP file from https, and the client app will connect to another SSL protected service, then I receive the following error message: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

In theory this message means, that the JVM can't find the truststore files, but I've printed out the system properties, and check the listed files, and they all existed. It could be the problem, that the remote end had the same host name, but different cert was installed there. I don't know whether this is a JDK or a GlassFish bug, but I'm certain, that when I download the JNLP file from HTTP, then the problem goes away.

Environment

Operating System: All Platform: Linux

Affected Versions

[v3.0.1]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/13291
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @tjquinno
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented aldaris@java.net said: This issue also occurs, while using asadmin get-client-stubs, and appclient --client .jar.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Are you able to attach your application to this issue? Or, if not, could you e-mail it to me privately? Also please let us know exactly what to do to reproduce the problem - exactly how you deployed the app, exactly what appclient command you used, etc.

In either case, please post the full exception and stack trace.

From your second entry which states that the problem occurs when launching the appclient command, it seems that you do not think Java Web Start is part of the problem. Is that correct?

You said you "...are certain that...[using] HTTP [instead of HTTPS for the Java Web Start launch] then the problem goes away." Does this mean that you actually saw the problem go away using HTTP for the Java Web Start launch or that you expect it to if you tried using HTTP instead of HTTPs? I do not understand how that relates to your observation that using the appclient script also fails because in that case Java Web Start is not involved in the client at all.

[glassfishrobot]

@glassfishrobot Commented aldaris@java.net said: I could attach my application, the only problem with it, that it is strongly coupled into a system. Actually I'm trying to connect with ClientSDK to an OpenSSO instance, so I'm going to try first recreate the issue in a smaller environment.

The deployment looked like: asadmin --port 14848 deploy --name korok --force

The appclient was ran with the following way: asadmin --port 14848 get-client-stubs --appname korok ~ appclient -client korokClient.jar

The Java Web Start way: go to admin console -> applications -> korok -> enable java web start -> save -> launch from there without arguments. (this will use localhost and http) wget --no-check-certificate https://:18181/korok/sch-pek-app-client-2.4-SNAPSHOT (the HTTPS way) javaws -verbose -wait sch-pek-app-client-2.4-SNAPSHOT

The problem is, that the exception was throwed in the library and it's not a full stacktrace... This problem occurs with the appclient command, and running the JNLP file downloaded from HTTPS. When I download the JNLP from admin console or HTTP, then the client app is working.

[glassfishrobot]

@glassfishrobot Commented aldaris@java.net said: Created an attachment (id=4812) The application has been simplified a bit, you just need to press the button, and see the exception

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: Marking target milestone as MS 7. I hope to get to this before then, though.

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: When I try to use maven 2.2.1 to build the app it fails, unable to locate

hu.sch:sch-pek-ejb-impl:ejb-client:client:2.4-SNAPSHOT

from your repository.

Can you help us get past that point or perhaps just attach the EAR file?

Thanks.

[glassfishrobot]

@glassfishrobot Commented aldaris@java.net said: Created an attachment (id=5484) The binary file showing the problem

[glassfishrobot]

@glassfishrobot Commented aldaris@java.net said: The maven-ejb-plugin's generateClient config should create the ejb-client module, so I just attach the binary version, instead of debugging..

[glassfishrobot]

@glassfishrobot Commented @tjquinno said: The correct resolution for this should be "not a bug" but our JIRA set-up has no such status (yet).

Thank you for supplying the example application. I was able to reproduce the same errors you see.

You are seeing two separate problems that look similar.

1. As I can tell without looking at the source of your app client, the client tries to open a URL using https://stewie.sch.bme.hu/... Whenever Java connects to a resource using https, it uses an SSLSocketFactory to create the connection and manage security on that connection. This includes knowing what trust store to use in deciding whether to trust a server-side certificate.

The server at that site authenticates itself using a self-signed certificate. This means that the client side will not automatically trust the content from that site. The Java default SSLSocketFactory will look in the configured trust store, see that the self-signed cert from stewie.sch.bme.hu is not there and has no certificate chain to a trusted cert, and abort the connection.

a. I think that Java Web Start provides its own SSLSocketFactory which detects if a server-side cert is untrusted and then asks the user whether to trust that cert or not.

b. Neither your client nor the app client container provides its own SSLSocketFactory capable of doing something similar, so the attempt to connect simply fails because the server's cert is not trusted.

I am not sure why, when you launch using https://host:8181/xxx, Java Web Start aborts the connection to stewie.sch.bme.hu without prompting the user to accept or reject the certificate. This might be expected Java Web Start behavior or it might be a bug. In either case this is not under the control of GlassFish.

I suspect that if you added code to your client to provide your own SSLSocketFactory to be used when it connects to stewie then both problems would vanish. Or, you could add the self-signed cert to the trust store which Java Web Start uses. Or you could have Java Web Start use your own trust store instead and add the self-signed cert to that trust store.

This link

http://download.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html

describes the file locations and properties that are available for customizing how Java Web Start works, particularly with respect to trust stores and certificates.

tells what configuration

[glassfishrobot]

@glassfishrobot Commented File: 13291.tar.gz Attached By: aldaris@java.net

[glassfishrobot]

@glassfishrobot Commented File: sch-pek-ear-2.4-SNAPSHOT.ear Attached By: aldaris@java.net

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-13291

[glassfishrobot]

@glassfishrobot Commented Reported by aldaris@java.net

[glassfishrobot]

@glassfishrobot Commented Marked as won't fix on Thursday, December 2nd 2010, 6:17:15 am