Connections based on the Secure Socket Layer (SSL) or Transport Layer Security (TLS) depend on the server having an X509 digital certificate trusted by the client so the client knows that it is communicating with a trusted entity. The traditional paradigm for trusting SSL certificates of servers is to have a well-known Certification Authority (CA) issue the SSL certificate of the server, and for the client application to trust the CA's self-signed root certificate. This model is well established in the browser world where web-browsers such as Firefox have a list of CA certificates preloaded by Mozilla to setup trust for you. With browsers that are part of the operating system – such as with Microsoft Windows or Apple OS-X – the trusted CA certificates are part of the operating system itself so that all applications on the platform can establish trust for SSL/TLS connections.

While this model works very well for publicly accessible sites, such as banks, e-commerce, etc., the SKLES is designed to be used on internal networks by internal applications. As such, not only is an SSL server certificate for the SKLES appliance a waste of money, it is also counter-intuitive for security. Ideally, you want unknown applications to fail to connect to the SKLES appliance even if they somehow have access to the appliance's web-service port.

For these reasons, StrongAuth creates self-signed SSL certificates for the appliance during the installation process. The SSL certificates are based on 2048-bit RSA keys with SHA256 message digests, valid for 10 years and are unique for each installation site. Thus, unless a client-application actually trusted this SSL certificate explicitly, the client-application would complain about the SKLES certificate.

To ensure that applications communicating with the SKLES – such as the strongkeyliteClient, the SetPIN Tool, the DACTool, etc. - can connect without errors to the SKLES, the installation process imports the newly generated SKLES certificate to the appliance's Java Virtual Machine (JVM) trust-store: the cacerts file in the JAVA_HOME/jre/lib/security directory. The cacerts file contains all the CA certificates approved by the creators of Java, and is distributed as part of the standard Java Development Kit (JDK) or the Java Runtime Environment (JRE).

By adding the SKLES' self-signed SSL certificate to the cacerts file of the default JVM, all Java applications on the SKLES can successfully communicate with the SKLES without any errors. Without the SKLES certificate in this file, the client application will display the following error message:

Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access the WSDL at:
https://demo.strongauth.com:8181/strongkeyliteWAR/EncryptionService?wsdl. It failed with:
 sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
 at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:151)
 at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:133)
 at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:254)
 at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
 at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:165)
 at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:93)
 at javax.xml.ws.Service.<init>(Service.java:56)
     at com.strongauth.strongkeylite.web.EncryptionService.<init>(EncryptionService.java:79)
     at strongkyeliteClient.Main.main(Main.java:109

Some sites may balk at having to import the SKLES SSL certificate into the cacerts file of the JVM as it modifies the “ default” installation of the JVM. They may prefer to maintain a different trust-store – a file containing certificates that are trusted by the client-application – for their application when connecting to a site. Since the SKLES uses Glassfish, which uses the Java Secure Socket Extension (JSSE), this is feasible through the use of two system properties: javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword. However, using a separate trust-store from the cacerts file requires that the application always be explicitly aware of the location of the custom trust-store file.

In order to use a different trust-store than the cacerts file, the SKLES SSL certificate must be stored in a Java Keystore (JKS) format file. The recommended location on the SKLES appliance is to use the /usr/local/strongauth/.keystore file. On Windows PCs where the SetPIN Tool or the DACTool may be used, it is recommended that the file location be C:\usr\local\strongauth\keystore; however, this is a matter of choice and can be anything you want as long as you specify the correct location of the file when executing the client application (shown below). On operating systems other than Linux or Windows, you are free to use any location for this file; however, you must specify the correct location of the file when executing client applications.

To create the trust-store file in the /usr/local/strongauth directory with the .keystore file-name, execute the following command:

keytool -importcert -file /usr/local/strongauth/skles01.der -keystore
/usr/local/strongauth/.keystore -storepass changeit -alias skles -noprompt

This command creates the .keystore file in the home directory of the strongauth user, and imports the SKLES SSL certificate (originally created by the installation script) into the trust-store with an alias of skles. The SSL certificate is automatically trusted because of the -noprompt option on the command line. The password for this file is changeit; however, you can use any password you wish for this trust-store file.

To create such a trust-store on Windows, you would execute the following command, assuming the skles01.der file is stored in the C:\tmp directory:

keytool -importcert -file c:\tmp\skles.der -keystore
c:\usr\local\strongauth\.keystore -storepass changeit -alias skles -noprompt

To use the new trust-store on the SKLES appliance with a client-application, such as the strongkeyliteClient, you execute the command as follows where you specify the location of the trust-store file in the javax.net.ssl.trustStore property and the password to the trust-store file with the javax.net.ssl.trustStorePassword property:

java -Djavax.net.ssl.trustStore=/usr/local/strongauth/.keystore
-Djavax.net.ssl.trustStorePassword=changeit -jar strongkyeliteClient.jar https://demo.strongauth.com:8181 1 encryptdecrypt Abcd1234! B 1001 1

In this manner, you can avoid having to modify the JVM's cacerts file, while continuing to establish trusted communications with the SKLES using custom trust-stores. Just remember that, because the JVM does not have the SKLES's SSL certificate in the cacerts file, all Java applications that must communicate with the SKLES must specify the location of the trust-store explicitly.