We are using Call studio 10.5, my colleague change his wsdl to https, for example, https://domainname.company.com:8444/project/generic?wsdl.
The old way I called the mule is, save the wsdl from ip address, and load the file into Web Service element, put the basic authentication in. That way it works fine. But once he change the wsdl url to https, I just try to modify all the "http" in address to "https", and I try one call. It said "Remote host closed connection during handshake", but under the environment, if I open the IE and access the wsdl url, it works perfectly. What do I missing there?
Did you try to recreate the element from scratch?
Is this a certificate trust issue, i.e. the tomcat does not contain the root certificate?
It might need to be imported in.
I agree with Gerry, sounds like a cert issue. If your endpoint is presenting a self-signed certificate or the cert was issued by a CA not in the default truststore, you'll have to add that to Tomcat's truststore.
Look at the certificate presented in IE by clicking on the address bar's lock icon, view the cert and look at the certification path. The "root cert" or CA needs to be in Tomcat's truststore. If its not, add it to the cacerts file at C:\Cisco\CVP\jre\lib\security\cacerts on your VXMLServer host. You'll have to use the keytool app in the jre/bin folder to add one.
EDIT: I missed that you're having issues in call studio, the same applies, except you'll be adding the cert to call studio's JRE. probably at ..\Cisco\CallStudio\eclipse\jre\lib\security
I just tried on my local,and I just generate the trust store file, load back the trust store file, and set the protocols property to TLSv1.2 and it seems works. Will try on the UAT environment side when my boss confirm that we can change the code.
If you are running your web server on TLS 1.2 only mode then it may fail during the TLS handshake with VXML Server. VXML Server by default sends TLS1.0 request. So if you want TLS 1.2 support on VXML Server you should be installing CVP 10.5 - ES26 on your VXML Server.
Yup, that is what I tried. I make a java class to set the https.protocols property to TLSv1.2, and it works at the moment. Hopefully in the future we don't have any other problem like PKIX issue etc.
Also need to make sure the address of the web service is DNS, and the website use valid wildcard certificate. The easy way to check is open that wsdl in the browser, if you see Secure or valid certificate in the header, then check the certificate is wildcard certificate, then for IVR should be OK.