When I asked myself the question “So what’s different between my local PC (where things work fine) and my server PCs (not working)?”, the first answer I came up with was, maybe the installed trusted SSL root certificates?
Thus, probably not a protocol mismatch issue.
Specifically, in my case, the server had an SSL key signed with ECDSA (not RSA), and my problematic client PCs were configured to use only ECDSA (not RSA) cipher_suites. In my case, the problem was caused by there being no match between the set of cipher_suites supported by the client, and the set of values that the server was able to accept. Note 3: Don’t use Registry Editor (as suggested here) unless you know what you’re doing. Note 2: If you’re reading this post after August 2016, check and make sure the new cipher_suites value that you add is one that’s still cryptographically valid. Note: This solution will only help if the remote server is configured with an SSL key that has an ECDSA (not RSA) signature, but all of the the cipher_suites that the client PC is configured to support are RSA (not ECDSA). Connecting to from my local workstation using Internet Explorer 11 also worked fine.However, connecting to using the Chrome browser from that same client PC worked fine.If this error persists, contact your site administrator.” Error message: “Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to again. Symptom 2: In Internet Explorer 11, attempting to connect to failed. The exact same C# program worked fine when I ran it from my local workstation as the client PC (connecting to the same remote server).The program did work fine to make connections to all other HTTPS URLs that we had tried.Error message: “The request was aborted: Could not create SSL/TLS secure channel.” Symptom 1: In a C# program, an attempt to establish an HTTPS (SSL / TLS) connection to failed.
The client computers affected by the issue were a pair of servers, running Windows 2012 R2 and Windows 2008 R2, respectively.įor the purposes of this post, I’ll use as the URL of the remote server. I recently did troubleshooting for, and managed to successfully fix, an issue where HTTPS connections to a specific remote server were failing to be made successfully.