1

I know that there are many references to this error but I am struggling to resolve the issue despite looking at and trying many of the suggested solutions.

The error only happens on certain machines. It does not happen on my dev machine nor on many others but we are able to repeat this on a Windows 2008 RS server as well as Windows 2012R2 as well as possibly others.

I am able to reach the page in a browser on the affected machine so this would exclude a lack of ciphers (or so I was told).

Each time I run my simple code I get the same error on some machines:

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

My simple code is this:

 Private Async Function CallRest() As Task

        Using http As HttpClient = New HttpClient()
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

            Dim url As String = "https://www.zeidman.info/appreg/resttest.php"

            Dim result = Await http.GetAsync(url)

            Dim content = Await result.Content.ReadAsStringAsync

            Console.WriteLine(content)
        End Using


    End Function

I have tried adding:

ServicePointManager.Expect100Continue = True

For testing purposes I have tried adding:

ServicePointManager.ServerCertificateValidationCallback = AddressOf AcceptAllCertifications

with the corresponding function

Public Function AcceptAllCertifications(sender As Object,
    certification As System.Security.Cryptography.X509Certificates.X509Certificate,
    chain As System.Security.Cryptography.X509Certificates.X509Chain,
    sslPolicyErrors As Security.SslPolicyErrors) As Boolean


        Return True
    End Function

I also saw this answer and used that version of the ServerCertificateValidationCallback but the code does not even go into that method (I put logging inside it)

One comment in this question suggested a system.net trace and despite following the instructions I have not been able to get that to show any output.

Any suggestions would be very welcome.

zeiddev
  • 662
  • 7
  • 23
  • 2
    First thing: move `ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12` on top of everything (before you create a HttpClient instance). 2) .Net 4.5+ must be installed in the target machine. 3) That site uses TLS12 only, the cipher suite is `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`, which is one of the default TLS12 ciphers, it can be used to encrypt a symmetric key in the SSL handshake (not a signing-only cipher). 4) HSTS is disabled, so setting a `user-agent` header is not strictly required, but it should be done anyway, for generic compatibility. – Jimi Nov 21 '19 at 16:58
  • 3
    5) That a Web Browser can connect to the remote server is not relevant, the browser may use its own cipher suites. 6) Both SHA and SHA-256 are needed: sometimes, someone or *something*, disables SHA on servers (to *enforce security*. That's a failure). If you have determined that TLS12 is available in the target machine, I suggest you read this: [SCHANNEL event logging](https://blogs.technet.microsoft.com/kevinjustin/2017/11/08/schannel-event-logging/) and download this: [Microsoft Message Analyzer](https://www.microsoft.com/en-us/download/details.aspx?id=44226) for testing. – Jimi Nov 21 '19 at 16:58
  • 2
    Side notes: you should use a static (`Shared`) HttpClient, setting defaults *manually* using a specific [HttpClientHandler](https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler). It's the HttpClientHandler that should manage the `ServerCertificateCustomValidationCallback`, handle `AllowAutoRedirect` and the `CookieContainer`. Always add a CookieContainer when connecting to web sites. The User-Agent can be specifies with `[HttpClient].DefaultRequestHeaders.Add("User-Agent", "A not so recent User-Agent header")`. *Not so recent* because HSTS is not supported yet. – Jimi Nov 21 '19 at 17:11
  • 1
    This can also be useful, to verify the system update status of those machines: [Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows](https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi) (applies to Windows Server 2012, Windows 7 Service Pack 1, and Windows Server 2008 R2 SP1). – Jimi Nov 21 '19 at 19:01
  • This happen in W7 Os based. I wrote another answer about that here: https://stackoverflow.com/questions/58857996/forcing-httpclient-to-enforce-tsl-higher-than-1-0/58862331#58862331 – G3nt_M3caj Nov 21 '19 at 19:42

1 Answers1

1

I got this to work. Thank you Jimi for all your suggestions. Very helpful.

It was your point 5 that got me thinking again. I ran the analysis from SSL Labs on the server that I was trying to connect to and saw that there were only four ciphers available. On my Win2008R2 client I used IISCrtypto to see which ciphers were installed. I saw that there were no matches for the ones on the server. I added the missing ciphers, rebooted and I was able to reach the site.

One thing I saw was that before Internet Explorer could not reach the site but afterwards it could so it clearly was using the built in Windows ciphers.

zeiddev
  • 662
  • 7
  • 23
  • I'm glad you got it to work. It would be useful to know if you have determined the reason why those ciphers were missing. The server wasn't updated? – Jimi Nov 22 '19 at 18:22
  • Yes I think so. It was a demo server that we just reused and didn't patch. It was our clients that were reporting the issues. – zeiddev Nov 22 '19 at 22:09