Forum Discussion

nemesdaniela's avatar
nemesdaniela
New Contributor
3 years ago

Error javax.net.ssl.SSLHandshakeException found on v5.6.1 and 5.7.0

-> javax.net.ssl.SSLHandshakeException found on v5.6.1 and v5.7.0

All the written suites under version 5.6.0 that used to work without any certificate configured on the test environment stopped working after upgrading to v5.6.1 and later on to 5.7.0.

 

Why do we need to have a certificate taking into account that we run these tests mostly on test environments that use self signed certificates?

 

We used all the old responses on this topic found on the forum and also on stack overflow and other websites but with no success. We also added a self signed certificate into Preferences > SSL Settings but because it is a self signed certificate it still didnt work (we do not expect nor want to add an authority signed certificate in the test environment).

 

How can we bypass the certificate verification? Is there any way to bypass this in a test environment? We already spent a lot of time figuring out how to fix this issue and its no longer worth our time now. If new releases do not seek a real solution for this (something similar to what Postman has), we might need to give up Soapui for a better tool.

 

We tried everything that we could find yet we are still stuck with 5.6.0 because of the SSL issue.

Any help on this issue would be highly appreciated.

Thank you

  • KarelHusa's avatar
    KarelHusa
    Champion Level 2

    Hi nemesdaniela ,

    It seems from the log it's the server who terminates the handshake not the client (SoapUI). More detailed error log would help to recognize.

     

    Does the remote server require client certificate (i.e. using Two-way SSL) or not (One-way SSL)?

     

    What happens if you try to open the WSDL in the web browser? Does it work? Does the browser complain about the server sertificate?

     

    Similarly as you suggest, some time ago I raised a feature request to ignore the remote server certificate issues, see:

    https://community.smartbear.com/t5/SoapUI-Feature-Requests/An-option-to-ignore-SSL-certificate-issues/idi-p/222436

     

    Best regards,

    Karel

     

    • nemesdaniela's avatar
      nemesdaniela
      New Contributor

      Hello KarelHusa,

       

      The logs are misleading, as the devs added more log tracking and used Wireshark to track the exchanged packages: some logs indicated that the client stopped the connection, some that the server automatically closed it. As a result it is very hard to say what actually went wrong. Our thought is that the server somehow stops the handshake as the certificate is self signed and SoapUI does not handle certificate validation bypass.

      From what my colleagues said, the server does require a client certificate, it is using Two-way SSL.

       

      If I run the tests in Postman it says that there is an error as the certificate is self signed but I can bypass the certificate validation and I can continue with the next request.

      Error: self signed certificate
      After ▶ Enable SSL certificate verification  - marked as disabled
      Warning: Self signed certificate

       

      If I try to open the WSDL in the browser, yes the browser does complain about the certificate but again, I can accept the risk and bypass the certificate validation.

      The idea remains, we do not plan on having anything else but self signed certificates in the test environment and the only difference at the moment is:

      - Even if we add the self signed certificate in the SoapUI config in 5.6.1 and 5.7.0 -> the SSL verification fails. Without this configuration it fails also.

      - With 5.6.0 we do not have any SSL config added into SoapUI and it works without any errors.

       

      If someone has any idea on how to get 5.7.0 working with the certificate bypass option, it would be highly appreciated. Any hack would be good at the moment since SoapUI does not have it implemented and I guess will not implement it taking into account that also other people requested it in the past without any resolution.

       

      Thank you,

      Daniela