Call External "Could not establish underlying trust relationship for the SSL/TLS secure channel"
Article ID: 209007
Updated On:
Products
Issue/Introduction
Gen 8.6 Workstation Toolset Call External statement fails to connect to a Gen EJB Custom Web Service running under a secure SSL/https WebSphere website with error:
Error: WSDL Access
Detail:
The underlying connection was closed: Could not establish underlying trust relationship for the SSL/TLS secure channel.
Cause
A (CA Root) certificate had not been installed for the WebSphere https website (port 9443).
Resolution
After installing the certificate it was also added to the Trusted Root Certification Authorities store for the Toolset client-side access via Internet Explorer (IE11) browser using these steps: Install Root Certificate in Internet Explorer
The error was then resolved and the Custom Web Service Operation displayed successfully in the Call External WSDL Method dialog box.
Additional Information
1. The Call External feature uses a .NET library to parse the WSDL. It uses default behaviour when it tries to connect to an SSL /TLS based server to retrieve the WSDL where proper SSL handshaking needs to occur.
Currently, the parser defaults to .NET Framework 4.0 and is able to understand a variety of issues with a certificate. If the certificate is not a valid one, it will not allow proceeding further and most of the time certificate issues could be fixed by working with the certificate provider.
For the specific case when presented with a self-signed certificate, the parser is able to recognize this and a message "Certificate is Self-signed/Invalid. Do you want to continue?" is displayed to allow the user to continue:
Related Gen 8.6 documentation: Add a Call External Statement > Call External Statement in Action Diagram > Consume a Secure Web Service
2. The most common issue with certificates are expired certificates and if the server presented an expired certificate, the Call External statement will not proceed and a generic error message will be received and sometimes a specific message based on what certificates are used on the server-side. In that case check for:
a. An expired certificate. There is no way to work around it.
b. If a client certificate is required. Certificates are trust operations and if encounter a certificate which doesn't match any installed trusted sources in the certificate store the certificate can be installed and set to be trusted.
c. A self-signed certificate. Per above, the Gen parser has been provided with a way to continue.
d. Checking if the wsdl URL will load successfully into a browser window can help with the troubleshooting - certificate related messages may be received.
3. As a workaround to speed resolution, the WSDL Document could be copied to a file on disk and then instead of typing in the URL use the folder/file option to access the saved WSDL document.
If the wsdl file can be loaded successfully by the browser then it should be possible to save a copy of the file locally.
If WebSphere is the application server then the wsdl file will reference a second .xsd file which also needs to be saved locally.
For example for wsdl file PStep.wsdl the contents will reference PStep_schema1.xsd. Access them both from a browser and then save locally to the same directory e.g.
https://hostname:9443/SMgr/PStep/PStep.wsdl
https://hostname:9443/SMgr/PStep/PStep_schema1.xsd
NOTE: At runtime execution of the application to call the SOAP Web Service, the Call External File has an option to choose whether Server certificate is turned on or off (on by default):
Add a Call External Statement > Call External File
Feedback
