none
Periodic SSL Handshake Fail using HttpWebRequest RRS feed

  • Question

  • Hi All,

    I am using a 3rd-party API that uses HttpWebRequest to create a secure connection to a web site. This was running fine until we upgraded from .net 4.0 to .net 4.5 (albeit I haven't found any evidence that this is a cause).  A few days after the upgrade, the occasional "The request was aborted: Could not create SSL/TLS secure channel.." is raised.  These failed handshake incidents account for approx 5 % of requests whilst the remainng 95 % succeed, using the same IIS service on the same windows server.  A system/net trace has revealed the following:

    System.Net        Information        0              [5212] Connection#23250319 - Created connection from <sourceip> to <destip>.

    System.Net     Information        0              [5212] TlsStream#7926280::.ctor(host=<host>, #certs=0)             

    System.Net        Information        0              [5212] Associating HttpWebRequest#54779151 with ConnectStream#4227661   

    System.Net        Information        0              [5212] HttpWebRequest#54779151 - Request: GET <uri>

     HTTP/1.1

    System.Net        Information        0              [5212] ConnectStream#4227661 - Sending headers

    {

    Host: <host>

     }.

    System.Net        Information        0              [5212] SecureChannel#38048949::.ctor(hostname=<host>, #clientCertificates=0, encryptionPolicy=RequireEncryption)

    System.Net        Information        0              [5212] SecureChannel#38048949 - Left with 0 client certificates to choose from.

    System.Net        Information        0              [5212] Using the cached credential handle.

    System.Net        Information        0              [5212] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = (null), targetName = api.ooyala.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation) 

    System.Net        Information        0              [5212] InitializeSecurityContext(In-Buffer length=0, Out-Buffer length=150, returned code=ContinueNeeded).         

    System.Net        Information        0              [5212] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4ba618:4d7e18, targetName = api.ooyala.com, inFlags = ReplayDetect, SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)

    System.Net        Information        0              [5212] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=ContinueNeeded).

    System.Net        Information        0              [5212] InitializeSecurityContext(credential = System.Net.SafeFreeCredential_SECURITY, context = 4ba618:4d7e18, targetName = api.ooyala.com, inFlags = ReplayDetect,

    SequenceDetect, Confidentiality, AllocateMemory, InitManualCredValidation)

    System.Net        Information        0              [5212] InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=IllegalMessage).

    System.Net        Error      0              [5212] Exception in HttpWebRequest#54779151:: - The request was aborted: Could not create SSL/TLS secure channel..               

    System.Net        Error      0              [5212] Exception in HttpWebRequest#54779151::GetResponse - The request was aborted: Could not create SSL/TLS secure channel..            

    "returned code=IllegalMessage" being here.

    I have tried updating the Client protocol request to SecurityProtocolType.Ssl3, verified the cert in the personal/intermediate store for IIS identity access.  The erratic nature of the failure leads me to consider it may be perhaps something on the remote server side (e.g. load balanced to a different server)?  I wouldn't have though its a AppPool Identity permission to cert private key problem as most of the requests succeed.  We have a Java service running on the same box hitting the same service with no issue. I therefore things its something unique to the Microsoft HttpWebRequest pipeline.

    Any pointers would be much appreciated.

    Environment :

    Windows 2008 R2 x64

    IIS Server targetFramework 4.5

    Tuesday, October 7, 2014 12:57 AM

All replies

  • You might need to modify the register key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL“ to achieve what you want.

    For details, please check this KB article(https://support2.microsoft.com/kb/933430/en-us?wa=wsignin1.0) and search for “Method 3: Configure Schannel to no longer send the list of trusted root certificate authorities during the TLS/SSL handshake process”.

    Tuesday, October 7, 2014 8:48 AM
  • Thanks for the suggestion Marizos. It appears the buffer limitation is on the server side providing the list of cert authorities, where in this case I'm working from the client side. This being the case I'm following up with the owners (another company) of the servers to find out what OS they're running and weather SChannel is the agent dispatching the CA list. 

    I'll let you know..

    Wednesday, October 8, 2014 4:23 AM
  • So it appears the server is not running SChannel as it is a Linux box. So I think the above fix around SChannel is out as a cause!
    Monday, October 13, 2014 1:31 AM
  • Hi,

    "The request was aborted: Could not create SSL/TLS secure channel." error, which can be solved by using the Windows HTTP Services Certificate Configuration Tool and information I obtained here.

    Thanks.

    • Proposed as answer by gferyt gfdh Monday, October 20, 2014 5:43 AM
    • Marked as answer by Shawn ZhaoModerator Thursday, October 23, 2014 1:30 AM
    • Unmarked as answer by BrianBoru Friday, October 24, 2014 4:19 AM
    Monday, October 20, 2014 5:43 AM
  • Thanks again Marizos,

    I've  done quite a bit of checking around client certs and trust storage but currently I don't think this is the problem, esp given failure is erratic and appears on the face of it to be coming from the server (ie running clients on separate servers all appear to start failing within minutes of each other). I have the remote server owners currently investigating on their side. Will update with resolution soon. 

    Friday, October 24, 2014 4:24 AM
  • Did you ever find a solution to this as I have what seems to be the very same issue. Even the pass/fail rate is about the same.  The only solution found was a retry loop: usually it works on the first retry after a failure, but i'd like a better solution if one exists.
    Friday, May 15, 2015 1:56 PM
  • Not exactly. I ended up using a similar approach to iterate the call a few times until a 200 is returned.  I suspect in my case, the problem may have been related to the distribution of requests to certain CDN node(s) or API servers, which would continue to fail on the SSL handshake.  I was unable to identify a particular API server from network traces as the same 'front-end' server id was returned for each request.
    Monday, May 18, 2015 11:33 AM
  • This sounds like it's not related to your situation exactly, but I wanted to share this related issue that others might see.  

    Basic Summary:

    HttpWebRequest throws error a connection error when a TLS key on the server is changed. Specifically this is the implementation done by CloudFlare. Every hour, on the hour xx:00 a web service fronted by CloudFlare will throw the following exception on the first execution, but all subsequent ones succeed:

    There's a link to the Windows patch at the bottom of the comments:

    https://github.com/dotnet/corefx/issues/3889

    Thursday, December 29, 2016 6:59 PM