This article describes a situation where Signdoc Standard accesses external KTA Webservice using HTTPS protocol and the connection fails due to certificate issues. The content of this article mainly describes problems in conjunction with KTA Webservice, but also can be applied to troubleshoot certificate issues in combination with other external Web Server resources used via KSD (for instance SMS Notification Plugin)
Problem: The KTA Statechange Notification is not returned to KTA and Cirrus.log file shows following problem:
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
(Please follow the knowledge base article How to troubleshot connectivity Problems between Kofax TotalAgility and Signdoc which gives detailed information about how to activate and increase loglevels for troubleshooting)
The Java Client (in this case the TOMCAT Server hosting the Signdoc Standard application) checks if the certificate installed at KTA Web Server is valid and can be trusted or not (based on the JVM´s trust store). This certificate is not valid, because it has been selfsigned, or signed by a certification authority which isn´t officially trusted (internal CA), therefor connection to KTA WebServices fails with error:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
How to solve the problem:
You need to install and import the certificate used by KTA Server to the local JVM Store.
How to achieve this:
1. First, you need to obtain the public certificate from the KTA Webservice . This can be done in a variety of ways, such as contacting the server admin and asking for it, or connect to the KTA Webservice via a Web Browser (for instance Google Chrome) and download/export the public certificate into a file.
2. Once you have the certificate saved in a file you need to add/import it to your local JVM´s trust store,--> a file called "cacerts". This file includes the public certificates of the well-known Certifying Authorities. In case of SignDoc Standard version 2.1, the cacerts file is located in directory ..\184.108.40.206.0.66\service\bin\jre\lib\security.
3. Import the certificate with the java tool "keytool" with a user who has permission to write/modify the cacerts file. Open a command prompt and navigate to the directory %JAVA_HOME%\bin and execute following command:
keytool -import -file <the cert file> -alias <some meaningful name> -keystore <path to cacerts file>
keytool -import -file c:\temp\server.crt -alias TEST -keystore C:\signdoc-standard-220.127.116.11.0.66\service\bin\jre\lib\security\cacerts
Executing the command will most likely ask you for a password. The default password as shipped with Java is "changeit".
After the successful import of the certificate the problem should be solved, and KTA StateChange Notification should be transmitted correctly to KTA Webservice.
If you still have problems with certificates related to Kofax SignDoc please contact Kofax Technical Support via creating a new case in the support portal https://support.kofax.com for further support.
Level of Complexity
|Kofax Signdoc Standard||2.1|