Java Web Start代码库证书链

Question

I'm using Java Web Start (JWS) to deploy and run my JavaFX application. The jnlp element of my jnlp file is defined as follows:

<jnlp spec="1.0+" xmlns:jfx="http://javafx.com" codebase="http://www.example.com/software" href="MyJnlp.jnlp">

My application successfully launches using the configuration above. I'm now trying to adjust the jnlp file such that the jars are downloaded over SSL. I purchased and installed an SSL certificate for my domain. I've confirmed that the certificate was successfully installed by pointing my browser to https://www.example.com/software/MyJar.jar and verifying that the jar is downloaded.

I updated the jnlp element of my jnlp file as follows:

<jnlp spec="1.0+" xmlns:jfx="http://javafx.com" codebase="https://www.example.com/software" href="MyJnlp.jnlp">

When I launch the application by double clicking the jnlp file I get a warning from Java stating that "The connection to this website is untrusted" and clicking on "More Information" I see a message stating that "The Certificate Authority that issued the certificate is not trusted" ( warnings pictured here )

My SSL certificate relies on a chain of SSL certificates to link it to a root certificate. I opened the Java console and verified that my root certificate is present under the System section of the Secure Site CA "Certificate Type" tab ( pictured here ).

As a test, I then tried importing my site's SSL certificate to the User section of the Secure Site "Certificate Type" tab. After my site's SSL certificate was imported I no longer received the warning.

Based on this test, it seems to me that Java may not be reading/able to read the intermediate certificates in the certificate chain that links my certificate to a root certificate.

I'd like my users to be able to launch the JWS application over https without importing my site's certificate or being prompted with a warning. Can anyone help?

Answer 1

Upon further investigation, it appears that my original suppositions surrounding the source of the failure may have been incorrect. I used openssl to view the certificate and certificate chain presented by the server hosting my Java Web Start codebase (I'm using openshift). The SSL data showed that although the SSL certificate for my custom domain was being presented, the certificate chain corresponded to RedHat's default SSL configuration (which obviously does not validate my custom domain's certificate).

My-MacBook-Pro:~ username$ openssl s_client -connect www.example.com:443
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=North Carolina/L=Raleigh/O=Red Hat Inc./CN=*.rhcloud.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
***CERTIFICATE FOR MY CUSTOM DOMAIN***
-----END CERTIFICATE-----

Since the server was presenting the certificate chain for openshift's default SSL support I decided to change the codebase attribute of my jnlp file to point to Redhat's provided domain which resolved the "Untrusted Connection" error.

I'm satisfied with this outcome. However, to use my custom domain I believe the right course of action would be to follow-up with Redhat to determine why the pem file which included my certificate chain is not being presented when accessing the server using my custom domain name.