Salesforce

Unable to manage a secure WSA instance from the OpenEdge Explorer Console or WSAMAN

Printable View
« Go Back

Information

 
TitleUnable to manage a secure WSA instance from the OpenEdge Explorer Console or WSAMAN
URL Name000041390
Article Number000188125
EnvironmentProduct: OpenEdge
Version: 10.x 11.x
OS: All supported platforms
Question/Problem Description
Unable to manage a secure Web Services Adapter instance from within the OpenEdge Explorer Console
Unable to manage a secure Web Services Adapter instance using the WSAMAN
Most settings for the Web Services Adapter instance are greyed out within the OpenEdge Explorer.

AdminServer log file contains the following error message:
Connection failure with WSA at https://myhost/wsa/wsa1 during list request, exception: The https protocol connection failed: javax.net.ssl.SSLException: Certificate not verified. (9990) (10770)

Connection failure with WSA during a list or deploy request:
$   wsaman -name <WSA name>  -list
$   wsaman -name <WSA name>  -wsm /<path>/myApp.wsm -appname myApp -deploy

AdminServer log file contains the following error message:
[WebServicesAdapter] Connection failure with WSA at https://myhost/wsa/wsa1 during deploy request, exception:
The https protocol connection failed: javax.net.ssl.SSLException: Connection has been shutdown:
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 (9990) (10770) 
Steps to Reproduce
Clarifying Information
The WSA status is okay when checking it from a Web Browser: https://localhost:8443/wsa/wsa1/ URL
WSA Web Services Status:wsa1:OK:111
The certificate was properly imported into the OpenEdge/certs directory.
Error Message
Defect Number
Enhancement Number
Cause
The AdminServer is unable to verify the certificate that is provided by the Java Servlet Engine (e.g. Tomcat) which is hosting the Web Services Adapter.

Deployment of a WSA app is done via the Adminserver, which makes it's own connection to Tomcat (with embedded WSA).
Even if tomcat has not been implemented with ssl and reverse proxy does ssl-offloading, the Adminserver initially makes an HTTPS connection to the secure WSA instance. Even for a local connection, the Adminserver is still a 'client' connecting to Tomcat.

When the Adminserver doesn't have the root certificate imported when making an HTTPS connection it fails. 
Resolution
Having secured the Web Services Adapter instance, import the appropriate root CA certificate into the client's (in this case Adminserver's) trust store (%DLC%\certs\psccerts.jar), so that the AdminServer trusts the root certificate: 
$   procertm -i <CA certificate>.crt %DLC%\certs\psccerts.jar 

The certificates loaded into psccerts.jar can be validated with:
$   procertm -l -v %DLC%\certs\psccerts.jar

If needed you can export the current Java Servlet Engine's (e.g. Tomcat) root certificate as follows:
  1. Go to https:/myhost/wsa/wsa1 in any modern web browser (e.g. Chrome, Edge).
  2. Open the certificate on the padlock icon and selecting View Certificate. 
  3. Go to the "Certificate Path" tab. 
Starting with the root certificate (the certificate at the top of the tree) follow the below steps for each certificate in the tree until the error is resolved: 
  1. Click on the certificate, then on "View Certificate". 
  2. Go to the "Details" tab. 
  3. Click on "Copy to File". 
  4. Choose "DER encoded binary X.509 (.CER)". 
  5. Save the file. 
  6. Use the procertm command as stated above to import it into the AdminServer's certificate store. 
Once the process is completed it is restart the AdminServer.
Workaround
Notes
Keyword Phrase
Last Modified Date4/21/2023 7:49 AM
Powered by