Question
CapGemini
US
Last activity: 14 Apr 2017 7:44 EDT
SSL handshake issue Rest connect
, I was still not able to find out the root cause. I have collected so many screen shots during my research during the week and as well in weekend.
Initially we had issue even connecting from SOAP UI tool. After configuring the SOAP UI tool to use TLS Version 1.2, it was able to make connection. Also, initially our XML format was in-correct and after fixing it we have received response from Hadoop Web service with response XML. We tried with Keys tore file in the SSL connection and without Keys tore file. Both situations the SOAP UI tool was able to get the response and expected results.
After referring Pega documentation, it was suggested to use the Key store file reference in the connect rule and where the file is imported into Data-Admin-KeyStore rule. I have created a keystore file with Hadoop SSL certificate imported into it and tried, but it did not work. Another suggestion was to add the Client Key Pair, but no success.
After this I have used the actual key store file that was created by Mike Mittman, in the Connect rule in Pega. The first error encountered was javax.net.ssl.SSLException: hostname in certificate didn't match.
, I was still not able to find out the root cause. I have collected so many screen shots during my research during the week and as well in weekend.
Initially we had issue even connecting from SOAP UI tool. After configuring the SOAP UI tool to use TLS Version 1.2, it was able to make connection. Also, initially our XML format was in-correct and after fixing it we have received response from Hadoop Web service with response XML. We tried with Keys tore file in the SSL connection and without Keys tore file. Both situations the SOAP UI tool was able to get the response and expected results.
After referring Pega documentation, it was suggested to use the Key store file reference in the connect rule and where the file is imported into Data-Admin-KeyStore rule. I have created a keystore file with Hadoop SSL certificate imported into it and tried, but it did not work. Another suggestion was to add the Client Key Pair, but no success.
After this I have used the actual key store file that was created by Mike Mittman, in the Connect rule in Pega. The first error encountered was javax.net.ssl.SSLException: hostname in certificate didn't match.
PDN suggested to update the Dynamic system setting, Which I have tried. Provided the screen shot below. But again this was led to the another repeating error “Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated” which were seeing multiple times during our research. We have created the service ticket with Pega already. This might be related to the configuration of Pega and how Pega is making the SSL connection and sending the certificate details to connect to the Hadoop end point. We need some tomcat server level debugging and trace the communication.
I am guessing that Pega is not picking up the certificate details from the Key store file and sending them to the Hadoop End Point. Scroll to the bottom to see the Pega ticket details. We need to figure out this quickly and fix it
***Moderator Edit: Vidyaranjan | Tagged SR Created***
Accepted Solution
Pegasystems Inc.
IN
Hello!
On reviewing the SR, we see that it has been resolved. SA-35040 was was created as a result of the investigation. Please reference that if you have the same question.
Thank you,
JPMorgan Chase & Company
US
Hi,
Could you please confirm Is it One-way or Two-way authentication.
To verify if Two-way SSL is configured in IBM Websphere, go to SOAP Endpoint(Server) Websphere server console, under SSL certificate and key management > SSL configuration > NodeDefaultSSLSettings > Quality of protection (QoP) settings, Client authentication should be set to "required", if its set to None, then its One-way SSL.
Once the right SSL connection type was determined to One-Way SSL, enable DEBUG on below classes :
1. Add “-Djava.net.debug=all” JVM argument to print all the transaction during SSL handshake.
2. Enable DEBUG on Pega package “com.pega.pegarules.integration.engine.internal.ssl.SSLUtils.java”
Pegasystems Inc.
GB
This SSL error:
javax.net.ssl.SSLException: hostname in certificate didn't match.
Indicates that 'hostname verification' mechanism is taking place; and this mechanism has found a discrepancy between the 'Common Name' (CN field in the endpoint's Certificate) and the DNS hostname used to reach the endpoint.
This can happen when you connect to an endpoint using its IP address, rather than its hostname.
Or it can happen if there is a Load Balancer (or other type of Proxy) between the client and the endpoint.
Or it can happen if the certificate really doesn't match the endpoint.
Also: I'm not sure whether SOAPUI will enforce the concept of Certificate 'trust' or not (it probably does, but I just don't know); so be careful of misleading results.
[Essentially it is the job of the client to decide whether it trusts the endpoint's Certificate; based on whether it has a local copy of the Certificate (or more typically) whether it holds a copy of the signing certificate of the endpoint's certificate: it *might* be that 'SOAPUI' decides to trust the endpoint without applying the concept of trust to it; that is this is a matter of protocol (as is 'hostname verification' and other mechanisms) rather than a matter of encryption/decryption per say.]
This SSL error:
javax.net.ssl.SSLException: hostname in certificate didn't match.
Indicates that 'hostname verification' mechanism is taking place; and this mechanism has found a discrepancy between the 'Common Name' (CN field in the endpoint's Certificate) and the DNS hostname used to reach the endpoint.
This can happen when you connect to an endpoint using its IP address, rather than its hostname.
Or it can happen if there is a Load Balancer (or other type of Proxy) between the client and the endpoint.
Or it can happen if the certificate really doesn't match the endpoint.
Also: I'm not sure whether SOAPUI will enforce the concept of Certificate 'trust' or not (it probably does, but I just don't know); so be careful of misleading results.
[Essentially it is the job of the client to decide whether it trusts the endpoint's Certificate; based on whether it has a local copy of the Certificate (or more typically) whether it holds a copy of the signing certificate of the endpoint's certificate: it *might* be that 'SOAPUI' decides to trust the endpoint without applying the concept of trust to it; that is this is a matter of protocol (as is 'hostname verification' and other mechanisms) rather than a matter of encryption/decryption per say.]
You really do need to find out whether the endpoint is one or two way SSL; because if it is TWO-WAY, then the server may (very likely to be doing this) well be failing the connection due to lack of trust of the client certificate.
CapGemini
US
Hi priti
Thanks
For your input where would I be checking for One way or Two SSL is this with at the Rest Service w are tryign to consume or Is this at Pega JVM end if so can you guys let me know how to check it in Tom cat
Thanks once again
CapGemini
US
I am not able to understand the SSL Log getting logged can you please let me know how to check if it is one way ssl or two ssl in a Tom Cat jvm and please let me how to disable the option
Pegasystems Inc.
IN
Hi Santosh,
Upon reviewing the SR details, I see that, currently there is active troubleshooting performed on your issue. I would suggest you to update the thread with the resolution steps at a later point in time as and when it is achieved. For now, we will avoid duplication of efforts here and in the SR.
Thank you for your cooperation.
Regards-
CapGemini
US
Hi Vidya
We have ran short of idea the SR has been open for close to a week now and we are still facing the same issue , I am trying multiple forums for some resolution
Thanks
Accepted Solution
Pegasystems Inc.
IN
Hello!
On reviewing the SR, we see that it has been resolved. SA-35040 was was created as a result of the investigation. Please reference that if you have the same question.
Thank you,