Unable to connect Footprints Sync to Exchange Web Services

When trying to configure Footprints Sync, the connection to port 443 on the Exchange Web Services may fail due to failing to negotiate with the Exchange server certification.

An error is displayed as below in the FootPrints logs.
- 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

 

PKIX path building failed:

When a TLS/SSL Certificate is applied to an external application, the local Java installation used by the Footprints may not get access to the root certificate authority (CA).  This will block adding the certificate to the Java datastore.
The error that appears in the Footprints.log, "PKIX path building failed" and "unable to find valid certification path to requested target", can be fixed using the steps below and the attached Java tool "UpdateCacertsTool".

Prerequisites:
1. IP address of the server that has the problem TLS/SSL certificate.  This can be the local Footprints server or an Exchange server on the domain.
2. The port that TLS/SSL is using to connect to the server. This could be 443 or 636 or 465

Steps to update the Java datastore:
1.    Create a working folder on the Footprints application server.
2.    Place the attached UpdateCacertsTool Java program to the location created in step 1.
3.    Start a CMD, DOS Console or Linux command prompt window with local Administration rights.
4.    Change working directory to the location created in step 1.
5.    Verify that the command window has access to the Java 8 runtime by running the command:  
 
If the command fails to execute then make sure the Java bin folder is part of your execution path.
6.    Execute the UpdateCacertsTool with the following command:  NOTE CASE SENSITIVE
 
            Provide the information requested by the program gathered as a prerequisite. It is recommended NOT to enable debugging output unless there are errors executing the program.
7.    If the program runs successfully a file called jssecacerts will be created in the same execution directory.
8.    Copy the jssecacerts file to the <java.home>/jre/lib/security folder.
9.    Restart Footprints application server Apache Tomcat service for the change to take affect.

The following snapshot shows a typical execution of the UpdateCacertsTool,

Note the red highlights, in particular the last one where success is indicated and additional instructions are provided for “deploying” the created jssecacerts file to the Java security folder.
 
IMPORTANT! There is no need to run this UpdateCacertsTool program for SSL communications that do not report the same error.
 
IMPORTANT!  Steps 6, 7 and 8 must be repeated for every SSL server connection reporting the same error. This may appear burdensome at first glance but it is necessary so that ONLY when no errors are encountered in the creation of the jssecacerts file it is “safe” to use it (i.e. copy it to the Java security folder.)  The UpdateCacertsTool program will look for the existence of the jssecacerts file in the Java security folder and if it finds it, it will use it in creating a new jssecacerts file that has the aggregate information.
 
IMPORTANT! If the Java installation is updated, it is possible that the jssecacerts file will be inadvertently deleted. Of course the jssecacerts file can be regenerated but it might be a good idea to keep a backup copy of it to save time.


UPDATE:
Attached PDF document shows a simpler way to configure certificate which will help when changes to the certificate are needed