“Failed to create SSL / TLS secure channel”, even though SCHANNEL reports “SSL server handshaking completed successfully”.

Question

I track the infamous "SSL exception" from unit test - in the same exception, current tests are generated in ReSharper, nunit from the console under my account and on build server integration tests. Locally, the code is launched from a Windows 7 computer with .NET 4.5.1 installed.

System.Net.WebException: The request was aborted: Failed to create a secure SSL / TLS channel.

I am sure this does not apply to certificates strictly, although they have been recently updated. (The exact time of the failure is close, but not certain - on the other hand, this is the most likely change in different environments.)

IIS is configured to require client certificates, and the HTTPS connection to the same endpoint is Green in Chrome. If I select an invalid client certificate in Chrome, I get a 403 message from IIS filed over a successful HTTPS connection.

Questions:

• Why (how can) the secure creation of the SSL / TLS channel is completed after the successful completion of the “handshake”?

• Is HTTP status rejected HTTP status 403 and is WebClient able to handle this factor? If not, this request may be left.

• What is a good next step in debugging a problem? Is there a specific controlled event to indicate success (or failure) after initial agreement?

---

Here's what was collected by fixing issues found in other posts:

• This is the end of the exception tree; there is no internal exception "Remote certificate is invalid according to the verification procedure", which I expect from a certificate error.

• When using all the logs for SCHANNEL, the server shows

  Acknowledgment of the SSL server completed successfully. The agreed cryptographic parameters are as follows.

  Protocol: TLS 1.0 / CipherSuite: 0x5 / Exchange Strength: 2048

• SSL confirmation / negotiation from a failed unit test looks "successful" on Wireshark. (It is not identical to the Chrome request and has a different consistent CipherSuite.)

• The HTTP client timeout is 100 seconds, which should be the default.

---

A little funny, the first failed test is ShouldCompleteSslHandshakeFor[InvalidClientCert] .

---

UPDATE: after viewing the local event viewer on the computer (do not ask why this happened to me) there are corresponding entries for failed connections:

(SCHANNEL) A fatal error occurred while trying to access the SSL client credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal state of the error is 10003.

This will definitely be a good reason why the encrypted channel failed after a communication failure.

Answer 1

Verify that the client certificate access process has access to the private key of the certificate.

MMC console with certificate plugin → Right-click the specified certificate → All tasks → Manage private keys.

Answer 2

Answers to my questions:

Why (how can) the secure creation of the SSL / TLS channel is completed after the successful completion of the “handshake”?

Secure channel encryption may still fail after the connect / negotiate phase, which only decides which certs / crypto to use. In this case, this is due to the fact that the private key (in the client certificate) is not available due to a security restriction.

Is HTTP status invalid HTTP 403 status and possible WebClient processing of this factor? If not, this request may be canceled.

No. The error is caused by the failure of SSL / TLS encryption before the server handler is even called. It was an erroneous question that grabbed a straw.

What is a good next step in debugging a problem? Is there a specific controlled event to indicate success (or failure) after initial agreement?

Look in the appropriate event logs — in this case, they were schannel logs for the local machine that reported the error message. Probably, an error would also be found if tracking was enabled, as described here .

Answer 3

I tried everything here for the same message, and it turned out that the permissions for the MachineKeys folder (C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys) should be granted to users on the server. MSDN article with general solutions to this problem