DAQ, certificate error talking to my.safersystem.com
If you get an error in the DAQ log like the following, it means that DAQ could not validate the certificate in the response from the remote
ERROR c.s.daq.service.DaqApiService : Cannot refresh configuration for https://my.safersystem.com:443. Error message is
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This should not normally happen. If it does, it probably means that a proxy server, whether legitimate (such as Blue Coat ProxySG, etc.) or
malicious, is interfering with the SSL communication between SAFER One DAQ and my.safersystem.com. Normal procedure for a legitimate proxy server
would be to add the proxy's certificate to the Java truststores used by DAQ. See below for full details.
Windows has a truststore (accessed via "Certificates" management console) where it stores certificates for entities that it trusts. By default,
it includes certificates for all of the major known "certifying authorities". If you receive a certificate that is not itself present in your
current truststore, as long as it was signed by a higher authority that is in your truststore, then that certificate will be trusted automatically.
For a completely unknown certificate that is not signed by one of the well-known special higher-authorities, you have the option to manually add
it to your local truststore, whereupon it will be trusted absolutely. Of course you should be careful before doing this to ensure that you really
know who it is that you are trusting.
SAFER One DAQ uses Java, and Java uses its own truststores completely separate from Windows, although they operate the same way. Therefore, it is
possible that a browser, such as IE, could successfully view a secure web site, while a Java application connecting to the same website might fail
with the above error, if the site's certificate is validated by the Windows truststore, but not by the Java truststore. In this case, neither the
actual certificate in question nor any of its higher-authority signers are currently present in the Java trust store which is being used for the
Java has a global truststore typically located in the file "C:\Program Files\Java\jre_version\lib\security\cacerts". Additional separate
truststores may also be created. Java applications can choose which of these truststore to use. Normal DAQ communications to my.safersystem.com
use the truststore file named "mysafersystemcom_jssecacerts" located at
"C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps\SAFEROneDAQ_version\WEB-INF\classes", if it exists, otherwise the global Java
trustore. The EarthNetwork interface in the local DAQ uses only the truststore named "jssecacerts" located in that same folder, and will fail to
start if this file is not found. The DAQ auto update task of downloading the new DAQ version from the server currently uses only the global Java
The reason why the above certificate error should not normally happen for my.safersystem.com is because our certificate is signed by "RapidSSL",
which is signed by "GeoTrust Global CA", which is one of the special certifying authorities that should already be present in every truststore,
whether Windows or Java. But also, our certificate is present in the mysafersystemcom_jssecacerts file, and should therefore be trusted directly.
Therefore, if DAQ writes the above error message in its log file, the most likely cause is that a proxy server is interfering with the SSL
communication between SAFER One DAQ and my.safersystem.com. The purpose of the proxy server is to inspect and control web traffic, especially SSL
traffic. This allows the IT overseers to view the contents of SSL communications in the name of security. Ironically, this is the same thing
that the bad guys do for malicious purposes.
The way it works is that the proxy server connects to the target web site on behalf of the requesting client, validates the site's certificate,
and then replaces it with its own, which is usually an unknown, untrusted, self-signed certificate, and then forwards the response to the client.
The problem comes when the client does not recognize the proxy's certificate and rejects the response as untrusted. The normal procedure when
using a legitimate proxy server is to add the proxy's unknown certificate to the local truststore used by the client application. In the case of
most web browsers, this would be the Windows truststore, but in the case of SAFER One DAQ, it would be the jssecacerts and
mysafersystemcom_jssecacerts files. Again, you need to be careful when adding a certificate to any truststore that you really know who it is that
you are trusting. Alternatively, it may be possible to add an exception to the proxy server so that traffic to my.safersystem.com is not
intercepted and modified like this.
If DAQ is writing the above error to the log file, you can test for the presence of a proxy server by using a web browser to connect to
my.safersystem.com. That alone may reveal some connection problems, but if it succeeds, you can view the certificate through the browser's
security options to see what it refers to. Normally the received certificate should be issued to my.safersystem.com and have
SHA1 thumbprint = 08:4B:09:6C:D1:9A:B4:6B:C8:C4:FC:2A:3A:D6:8A:AB:21:CB:23:46. If the certificate you receive is different, it is probably from
a proxy server. Do your best to verify the legitimacy of the received certificate before adding it to any truststore.
To verify that the problem with DAQ connecting to my.safersystem.com is definitely related to validating the certificate, you can temporarily
instruct DAQ to trust all certificates. Only use this setting as a temporary troubleshooting measure:
1. Stop Apache Tomcat service.
2. Edit application.yml located at "C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps\SAFEROneDAQ_version\WEB-INF\classes folder",
just below "daq:" insert the line, "ssl-trust-all: true". Mind the space after the colon character. Save the file.
3. Start Apache Tomcat service.
4. Watch the SAFEROneDAQ.txt file after the application gets initialized. Messages about “got status 200” and the absence of the certificate
error indicate that the problem is definitely related to certificate validation.
5. Revert to the previous application.yml settings.
The following command will identify the certificates present in a specified Java keystore file. Note that the term "keystore" is basically
synonymous with "truststore". Also, the default password for a Java truststore is "changeit", but it is not really necessary to use it for this
"C:\Program Files\Java\jre1.8.0_91\bin\keytool.exe" -list -keystore path_to_keystore_file
If it becomes necessary to add a proxy certificate to the Java truststores used by SAFER One DAQ as described above, you can either use the
-importcert function of the keytool.exe command together with an exported certificate file, or you can use a Java command included in the
SAFER One DAQ files as described below. This method is probably a little shorter:
1. Stop Apache Tomcat service.
2. In the "C:\Program Files\Apache Software Foundation\Tomcat 8.0\webapps\SAFEROneDAQ_version\WEB-INF\classes" folder, remove the two files
called “jssecacerts” and “mysafersystemcom_jssecacerts”.
3. From a command prompt, change the current directory to that path.
4. Run the command “java com.safer.daq.helper.InstallCert my.safersystem.com:443”. Some exceptions will be displayed and then a message about
“Server sent (one or more) certificates”. Then it prompts for what you want to do. Type “all” and enter to add all certificates.
5. If the command succeeded, it will have created a new “jssecacerts” file in that current directory. Make a copy of this file in the same
directory and name it as “mysafersystemcom_jssecacerts”. Make another copy of the file and name it as "cacerts".
6. Cut the "cacerts" file from this location, browse to the global Java truststore location, and paste the "cacerts" file, overwriting the
previous file there.
7. Start Apache Tomcat service and watch the SAFEROneDAQ.txt file after the application gets initialized. Messages about “got status 200” and
the absence of certificate error messages indicate success.
The "InstallCert" command first loads a copy of the jssecacerts file, if it is exists, or else the global Java cacerts file. It then uses this
list to validate the certificates received when connecting to the specifed website. Any unrecognized certificates along with the higher-level
signers in their chain of trust, will be displayed with an option to add them to the current list. The result is written to a truststore in the
current directory with the name jssecacerts, overwriting any previous file with that name.