Legitimate certificate considered untrusted

[mauromol]

Thank you very much for OpenWebStart!

It seems like CAs are now issuing code signing certificates in a different manner. New requisites of the CAB Forum are forcing them to create the private keys and store them in HSM hardware. Some of them have opted to store the private keys in a cloud environment, so you can't use jarsigner any more to sign your JARs, but you have to use their tool.

Actalis is doing it in that way. Now that our old certificate has expired, we're experiencing an issue with the JARs signed with Actalis tool: the certificate used to sign is considered untrusted by OpenWebStart, although it's validated correctly with Java Web Start. I tried to understand what is the difference between the JARs signed with the new certificate (and Actalis tool) and the JARs signed with the old certificate (and Java standard jarsigner). The certificate chain is the same and it is:

our certificate => issued by CN=Actalis Code Signing CA G2 => issued by CN=Actalis Authentication Root CA

I already verified that the cacerts of the JRE used by OpenWebStart does contain the root certificate, so I would expect OpenWebStart to validate the newly signed JARs correctly. However it does not.

The only difference I could find is that jarsigner seems to put also the root CA certificate in the RSA file in the signed JAR (so the one for CN=Actalis Authentication Root CA), while the new Actalis tool does not, and just puts the leaf certificate and the intermediate one (CN=Actalis Code Signing CA G2). However I would say that the Actalis tool behaviour is correct and that OpenWebStart should validate the certificate correctly, because the last certificate in the chain is indeed issued by a well known root CA. And Java Web Start likes it, indeed.

I'm attaching two TXTs: one with the output produced by OpenSSL over the certificate chain that OpenWebStart validates correctly (apart from the fact that the leaf certificate is expired last Friday, sorry) and one with the output for the chain that OpenWebStart does not validate correctly. The output I get from OpenWebStart in the second case is this:

RSA file validated correctly: verificationok.txt

RSA file validated as untrusted: validationko.txt

[mauromol]

By the way, tests were made with the latest OpenWebStart 1.8.0 version under Windows 10 64-bit.

[fleminra]

I already verified that the cacerts of the JRE used by OpenWebStart does contain the root certificate

I'm finding that for JAR verification, two keystores are consulted and respected (Linux client but Windows similar):

• $HOME/.config/icedtea-web/security/trusted.cacerts (as expected!)
• $HOME/.cache/icedtea-web/jvm-cache/adoptium_11.0.19_x64/lib/security/cacerts (surprise!)

For JAR verification, I'm having no luck at all with /opt/OpenWebStart/jre/lib/security/cacerts.

My circumstances are different than yours: I'm transitioning from one of those DigiCert hardware tokens to an in-house code-signing certificate (it's an enterprise application), and we're trying to figure out where we have to stick our in-house Root CA cert. And this is what I've found, that it works if it's installed in $HOME/.cache/icedtea-web/jvm-cache/adoptium_11.0.19_x64/lib/security/cacerts but not /opt/OpenWebStart/jre/lib/security/cacerts.

Could the OWS guys confirm this? Can OWS tell the downloaded JRE to use a different cacerts, e.g. by deployment.system.security.trusted.certs? I'll try that next.

[fleminra]

Just to follow up on my last comment, I found a way for OWS to trust an application signed by an in-house certificate:

Create a deployment.config or itw-deployment.config. On Linux it should be in /etc/.java/deployment/.

This .config file should contain something like this:

deployment.system.config=file\:/etc/.java/itw-deployment.properties
deployment.system.config.mandatory=true

(Not totally sure whether the .mandatory setting is required for this to work.)

Then /etc/.java/itw-deployment.properties should contain:

deployment.system.security.cacerts=/etc/ssl/certs/java/cacerts

... which is the standard location for Debian & derivatives. RHEL & relatives use /etc/pki/java/cacerts.

Or you could point to the cacerts of the JRE bundled with OWS, if you have more control over the OWS package than the cacerts file under /etc/.

Then just make sure that that cacerts file contains the root CA cert that issued your code-signing cert.