When validating a Web Services (WS) connection profile that uses an https url, the following error is displayed:

Validation failed  
Account <REST>: REST location validation has failed

REST location validation: failed
   Failed to reach 'https://openexchangerates.org/api/currencies.json' Error: 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:: 

The same error can also appear in the WSDL Submit log in the Control-M/Agent's proclog directory when the error occurs while running a WS job.

 

The error occurs because the Control-M for Web Services module (or rather, the Java runtime environment JRE that runs it) was not able to validate the certificate presented by the https URL's web service.  It means that the trusted root certificate store of the JRE does not contain the CA certificates of that signed this service's certificate. This article and the following video explain how to easily obtain and import those certificates.

1. Log on to the Agent machine, open IE browser and enter the https URL of the web service
2. When the browser return the WSDL page result, click the lock icon in the url field and them select View Certificates.
3. Go to the Certification Path tab, and for each of the one or two certificates in the tree above the current one (The Root CA and optional Intermediate CA), select that certificate and click View Certificate
4. Click Details tab, click Copy to File.
5. Click Next, select the "Base64 encoded binary X.509 (.CER)" format and click Next.
6. Enter a location and file name to store this certificate file locally, click Next and Finish.
7. Once you have saved all CA certificates in the tree to a file, open a command prompt (As Administrator)
8. Change Directory to the <Agent>/cm/JRE/ directory.
9. Execute exactly as below:
   Windows: bin\keytool -import -trustcacerts -keystore lib\security\cacerts -alias <UniqueAlias> -file <full path to saved cert file>
   Unix: bin/keytool -import -trustcacerts -keystore lib/security/cacerts -alias <UniqueAlias> -file <full path to saved cert file>
   If using JRE 11 and Unix: bin/keytool -import -trustcacerts -alias <UniqueAlias> -file <full path to saved cert file> -cacerts
   If using JRE 11 and Windows: bin\keytool -import -trustcacerts -alias <UniqueAlias> -file <full path to saved cert file> -cacerts
   where: <UniqueAlias> is any unique name that identifies this certificate
   Note: Be sure to use the correct slash when running these commands.  If forward slash is used on Unix OS, an error will not be presented and you will receive a message that the certificate was imported when it did not actually import
10. Enter 'changeit' when prompted for password.
11. Enter 'y' or 'yes' to proceed with the import.
12. Once applied, restart Web Services on the Control-M/Agent using stopwscm

It is also recommended to install the latest fix pack :
ftp://ftp.bmc.com/pub/control-m/opensystem/Control-M_for_Web_Services_Java_and_Messaging/9.0.00/PACOB.9.0.00.007/

Additional Information:

1. If the Control-M for WJM is running fine and encountered this incident for no specific reason, it is recommended to restart the Web Service (Not Control-M WJM).

2. The above steps assume that you are using the default JRE with Control-M for Web Services.  If you have configured Control-M for Web Services to use a different JRE, then you must import the certificates into the cacerts keystore of that JRE - simply run the keytool command of that JRE and point to its cacerts keystore file. 

3. Similarly, the above steps assume you are using the default JRE keystore (cacerts) with Control-M for Web Services. If you have configured Control-m for Web Services to use different keystores, you should import the certificates to those instead.
The relevant configuration parameters can be found in the file <Agent>/data/wsprofile.dat

Please do the following steps to get the debug logs for further analysis:

1. Execute the stopwscm and make sure the WS CM's java process is terminated (open the Task Manager, set the View option to include the process's Command Line, and make sure the javaw.exe from the <Agent>\cm\WS\java is not there)
2. Clear the Agent's PROCLOG files, set Agent debug 4 (agdbglvl 4 to turn on, agdbglvl 0 to turn off).
3. Submit the problem job, then open the ctmas log and find the line that contains "javaw", copy the "<path>\javaw.exe ..." line, and place it in Notepad.
4. Remove the "w" from "javaw" so that it is "java". Then insert "-Djavax.net.debug=all" right before the "-Djava.class.path=", for example:
   "<Agent>\cm\JRE\bin\java.exe" -Djavax.net.debug=all -Djava.class.path="...." ...
5. Do step 1 again to stop the WS CM java process.
6. Open CMD prompt, cd to the <Agent>\<instance> and execute the "java" line from step 4 manually.
7. Submit the problem job one more time.
8. Send us the CMD's java command output from step 6.