Error: The request was aborted :Could not create SSL/TLS secure channel

Cause 1:  

Mismatched Transport Layer Security (TLS) version between client (PhoneView) and server (Cisco UCM)

For example, If PhoneView send a TLS1.0 SSL handshaking/negotiation request to Cisco UCM and if Cisco UCM configured with only TLS1.2 then we will get such error.

Possible Solution: We need to change tls version in PhoneView config file so PhoneView will send same UCM TLS supported version request.

We can enable/disable TLS version in the PhoneView config file ("C:\Program Files (x86)\UnifiedFX\PhoneView\PhoneView.exe.config")

<add key="EnableTLS1.0" value="false" />
<add key="EnableTLS1.1" value="false" />
<add key="EnableTLS1.2" value="true" />
 

**Cisco Unified Communications Manager and IM and Presence Services, release 9.x supports TLS 1.0 only.

** By default, CUCM 10 and above supports a minimum TLS version of 1.0. If your security needs require a higher version of TLS, reconfigure the system to use TLS 1.1 or 1.2.

Verifying the Configured Minimum TLS Version of Unified CM

Cause 2:

Another possible cause of the request was aborted: Could not create SSL/TLS secure channel error is a mismatch between your client PC's configured cipher_suites values, and the values that the server is configured as being willing and able to accept. In this case, when client sends the list of cipher_suites values that it is able to accept in its initial SSL handshaking/negotiation "Client Hello" message, the server sees that none of the provided values are acceptable, and may return an "Alert" response instead of proceeding to the "Server Hello" step of the SSL handshake.

We have found due to Windows Security Updates for Windows 7, 8, Server 2008R2 & 2012 Server has broken SSL/HTTPS connectivity to certain Apache/Tomcat web servers (CUCM, UCCX). This issue is caused by the addition new Cipher Suites those names start with "TLS_DHE_*"
For Ex:-"TLS_DHE_RSA_WITH_AES_128_CBC_SHA”  “TLS_DHE_RSA_WITH_AES_256_CBC_SHA" etc.

"For some unknown reason" is simply that many clients freak out when they get DHE keys larger than 1024 bit.
It is very common - if not standard - to not use keys larger than 1024 outside Microsoft. Older Java clients breaking are a good example. This then includes many popular Oracle business products. Note these ciphers were - as I understood - only added to allow to meet newer NIST recommendations on forward secrecy, but still allow compatibility with older software.
Reference : https://community.qualys.com/thread/14821

Possible Solution: - Remove all ciphers start with TLS_DHE_ from following registry path

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002]

And then restart the system.

** Please take backup of above registry path before modifying the Cipher suites

We would like to recommend following IISCrypto software for above solution https://www.nartac.com/Products/IISCrypto/Download

Step1) take a backup of Cipher suites in IISCrypto –

Step 2) click Best Practices button this will remove all problematic ciphers from registry.

Step 3) Reboot the machine.