none
Azure WebApp / WebJob Exception "Could not create SSL/TLS secure channel"

    Question

  • I have an Azure WebJob which when run locally works fine, yet when run in Azure it throws an exception. The WebJob is making an external call over HTTPS which in Azure produces this exception:

    System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. at System.Net.HttpWebRequest.GetResponse()

    I also tried setting the security protocol to TLS using ServicePointManager but this too had no effect on the exception. Here's a snippet of my code.

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
    
    var request = (HttpWebRequest)WebRequest.Create(url);
                    request.Method = "GET";
    

    Also tried faking the certificate validation: ServicePointManager.ServerCertificateValidationCallback = delegate { return true; }; 

    Does Azure block WebJobs from internet access or am I doing something wrong?

    ** Update - Also fails when I make the same request from the website (WebApp) too. The Url is https://tls.so that I'm trying to make a request too. **

    Friday, May 29, 2015 12:56 PM

All replies

  • It's also worth noting, the endpoint I'm trying to connect to is using Cloudflare.

    I believe it's something to do with SNI and .NET on Azure?


    Friday, May 29, 2015 1:35 PM
  • Hi Ashley,

    To help isolate, do you get the same when you try to curl that same URL from your site's Kudu Console?

    thanks,
    David

    Friday, May 29, 2015 2:16 PM
    Moderator
  • Actually, I just tried from my site and I get this:

    curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

    However, if I try on my local box, I also get the same error. But from Chrome it works fine. So it seems there is something unusual about it, though I'm not sure what.

    Friday, May 29, 2015 2:21 PM
    Moderator
  • That's because the endpoint doesn't support SSLv3. That's why I tried forcing security protocol to TLS.

    It's semi related to this stack overflow article though there's no answer been provided. http://stackoverflow.com/questions/28650477/windows-azure-cloud-app-could-not-create-ssl-tls-secure-channel

    It's something to do with SNI I believe and .NET. If you have a look at the certificate / connection you're see the SNI.

    If there anywhere better I can reach out for help getting this resolved as it only seems related to running in Azure?

    Friday, May 29, 2015 4:46 PM
  • From Kudu using PowerShell/.Net

    [System.Net.WebRequest]::Create('https://tls.io/json.php')

    AllowAutoRedirect : True
    AllowWriteStreamBuffering : True
    AllowReadStreamBuffering : False
    HaveResponse
    AllowAutoRedirect                    : True
    AllowWriteStreamBuffering            : True
    AllowReadStreamBuffering             : False
    HaveResponse                         : False
    KeepAlive                            : True
    Pipelined                            : True
    PreAuthenticate                      : False
    UnsafeAuthenticatedConnectionSharing : False
    SendChunked                          : False
    AutomaticDecompression               : None
    MaximumResponseHeadersLength         : 64
    ClientCertificates                   : {}
    CookieContainer                      : 
    SupportsCookieContainer              : True
    RequestUri                           : https://tls.io/json.php
    ContentLength                        : -1
    Timeout                              : 100000
    ReadWriteTimeout                     : 300000
    ContinueTimeout                      : 350
    Address                              : https://tls.io/json.php
    ContinueDelegate                     : 
    ServicePoint                         : System.Net.ServicePoint
    Host                                 : tls.io
    MaximumAutomaticRedirections         : 50
    Method                               : GET
    Credentials                          : 
    UseDefaultCredentials                : False
    ConnectionGroupName                  : 
    Headers                              : {}
    Proxy                                : System.Net.WebRequest+WebProxyWrapper
    ProtocolVersion                      : 1.1
    ContentType                          : 
    MediaType                            : 
    TransferEncoding                     : 
    Connection                           : 
    Accept                               : 
    Referer                              : 
    UserAgent                            : 
    Expect                               : 
    IfModifiedSince                      : 1/1/0001 12:00:00 AM
    Date                                 : 1/1/0001 12:00:00 AM
    ServerCertificateValidationCallback  : 
    CreatorInstance                      : System.Net.WebRequest+DesignerWebRequest
                                           Create
    CachePolicy                          : Level:BypassCache
    AuthenticationLevel                  : MutualAuthRequested
    ImpersonationLevel                   : Delegation
    : False
    KeepAlive : True
    Pipelined : True
    PreAuthenticate : False
    UnsafeAuthenticatedConnectionSharing : False
    SendChunked : False
    AutomaticDecompression : None
    MaximumResponseHeadersLength : 64
    ClientCertificates : {}
    CookieContainer :
    SupportsCookieContainer
    AllowAutoRedirect : True
    AllowWriteStreamBuffering : True
    AllowReadStreamBuffering : False
    HaveResponse : False
    KeepAlive : True
    Pipelined : True
    PreAuthenticate : False
    UnsafeAuthenticatedConnectionSharing : False
    SendChunked : False
    AutomaticDecompression : None
    MaximumResponseHeadersLength : 64
    ClientCertificates : {}
    CookieContainer :
    SupportsCookieContainer : True
    RequestUri : https://tls.io/json.php
    ContentLength : -1
    Timeout : 100000
    ReadWriteTimeout : 300000
    ContinueTimeout : 350
    Address : https://tls.io/json.php
    ContinueDelegate :
    ServicePoint : System.Net.ServicePoint
    Host : tls.io
    MaximumAutomaticRedirections : 50
    Method : GET
    Credentials :
    UseDefaultCredentials : False
    ConnectionGroupName :
    Headers : {}
    Proxy : System.Net.WebRequest+WebProxyWrapper
    ProtocolVersion : 1.1
    ContentType :
    MediaType :
    TransferEncoding :
    Connection :
    Accept :
    Referer :
    UserAgent :
    Expect :
    IfModifiedSince : 1/1/0001 12:00:00 AM
    Date : 1/1/0001 12:00:00 AM
    ServerCertificateValidationCallback :
    CreatorInstance : System.Net.WebRequest+DesignerWebRequest
    Create
    CachePolicy : Level:BypassCache
    AuthenticationLevel : MutualAuthRequested
    ImpersonationLevel : Delegation
    : True
    RequestUri : https://tls.io/json.php
    ContentLength : -1
    Timeout : 100000
    ReadWriteTimeout : 300000
    ContinueTimeout : 350
    Address : https://tls.io/json.php
    ContinueDelegate :
    ServicePoint : System.Net.ServicePoint
    Host : tls.io
    MaximumAutomaticRedirections : 50
    Method : GET
    Credentials :
    UseDefaultCredentials : False
    ConnectionGroupName :
    Headers : {}
    Proxy : System.Net.WebRequest+WebProxyWrapper
    ProtocolVersion : 1.1
    ContentType :
    MediaType :
    TransferEncoding :
    Connection :
    Accept :
    Referer :
    UserAgent :
    Expect :
    IfModifiedSince : 1/1/0001 12:00:00 AM
    Date : 1/1/0001 12:00:00 AM
    ServerCertificateValidationCallback :
    CreatorInstance : System.Net.WebRequest+DesignerWebRequest
    Create
    CachePolicy : Level:BypassCache
    AuthenticationLevel : MutualAuthRequested
    ImpersonationLevel : Delegation

    Friday, May 29, 2015 5:13 PM
  • Would you be able to share a trivial console exe (e.g. sources on GitHub) that demonstrates the different behavior between what you see in Kudu Console and what you see on your local machine? That would help us investigate and make sure we try exactly the same thing as you.

    Note that SSLv3 being disabled should not cause this. In fact all Azure Web Apps have it disabled when you send requests to them. e.g. try running:

    curl https://davidebbo.azurewebsites.net/

    This works fine both from Kudu console (of a different site) or my local machine. But if I force it to use SSLv3, it fails:

    curl: (35) Unknown SSL protocol error in connection to davidebbo.azurewebsites.net:443

    Which is by design. But that's different behavior from your site, where curl fails even if you don't force it to use v3.

    Friday, May 29, 2015 6:40 PM
    Moderator
  • The issue isn't with making a request to an Azure WebApp, it's when I'm making a web request from within my WebApp/WebJob (I've tried both) to an external resource.

    var url = "https://tls.so/json.php?host=www.ashleypoole.co.uk:104.28.7.2&port=443&ciphersuites=1";
    
    var request = (HttpWebRequest)WebRequest.Create(url);
    request.Method = "GET";
    
    
    var response = (HttpWebResponse)request.GetResponse();
    var streamReader = new StreamReader(response.GetResponseStream());
    
    webResponseModel.Payloay = streamReader.ReadToEnd();
    The resource on tls.so is behind Cloudflare and SSLv3 is disabled, FYI.
    Friday, May 29, 2015 7:00 PM
  • Yes, it's understood that the issue is not about making requests to a WebApp. I was just using a WebApp as an example of a site that has SSLv3 disabled, yet that doesn't show the same behavior. This is to illustrate that while disabled SSLv3 may be a factor, it is not in itself a sufficient condition.

    I'll try your code sample, thanks!

    Friday, May 29, 2015 7:13 PM
    Moderator
  • I thought switching to RestSharp had solved this but it didn't :( 
    Friday, May 29, 2015 7:47 PM
  • We investigated, and there is indeed an issue that is blocking this scenario. Someone else will follow up with more details.
    Friday, May 29, 2015 11:04 PM
    Moderator
  • I think I know what's going on. https://tls.so has an ECC certificate and the cipher suites configured on the server are (from ssllabs.com):

    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   ECDH 256 bits (eq. 3072 bits RSA)   FS128TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   ECDH 256 bits (eq. 3072 bits RSA)   FS128TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   ECDH 256 bits (eq. 3072 bits RSA)   FS128TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   ECDH 256 bits (eq. 3072 bits RSA)   FS256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   ECDH 256 bits (eq. 3072 bits RSA)   FS256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   ECDH 256 bits (eq. 3072 bits RSA)   FS256TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)   ECDH 256 bits (eq. 3072 bits RSA)   FS112TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)   ECDH 256 bits (eq. 3072 bits RSA)   FS256

    For Azure roles, we have the cipher suite configured according to the list on https://msdn.microsoft.com/en-us/library/azure/dn775043.aspx. If you will notice in this list, all the ECDHE ciphers are PFS (perfect forward secrecy) ciphers as they have the PXXX in the end of the cipher. Since the server here does not support PFS ciphers, the TLS negotiation fails as there is no cipher that both the client and the server support.

    The goal of our cipher suite order was to have stringent security requirements for inbound TLS connections and we could relax the restrictions for outbound. I am conferring with our team on what the best approach is to address this is and I will get back to this thread when we have something planned. 

    Sorry for the trouble.


    Friday, May 29, 2015 11:11 PM
  • Thanks. Hopefully this is fixed sooner rather than later as it's preventing me from running my WebJob in Azure so I cannot fully deploy my site. Also looking through Stack Overflow, others have been having the same issue.
    Sunday, May 31, 2015 7:22 PM
  • Ashley - I worked around this issue by pausing CloudFlare. When using the SSL cert that I have uploaded to my website, it works just fine. I want to use CloudFlare long-term so I'm interested in this resolution as well, but pausing CloudFlare has let me move forward with my WebJob until this is resolved.
    Tuesday, June 2, 2015 9:02 PM
  • Thanks but sadly I don't own the web service that is running behind Cloudflare. It's this web service that my Azure WebJob is talking too.
    Tuesday, June 2, 2015 9:37 PM
  • Any update on a projected timeline for resolution?
    Tuesday, June 9, 2015 6:41 AM
  • Ok, my previous response was a bit wrong :) Its not a PFS thing, but ciphers supported in the particular TLS version.

    The client hello from .NET code running inside a web app shows that it is trying to use TLS v1.0 with TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ciphers that are obviously not supported on the server. In .NET 4.5 you can ask it to use a different protocol version and then things start working for me once I do that. Here's a code snippet:

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11;
    var response = WebRequest.Create("https://tls.so").GetResponse();
    var body = new StreamReader(response.GetResponseStream()).ReadToEnd();

    When you do this, I can see that the ClientHello tries to negotiate a whole bunch more cipher suites.

    So hopefully you can do a quick change to your app to get this working without worrying about the server. Sorry for confusion!

    Tuesday, June 9, 2015 9:31 PM
  • This still didn't work. As you see in my first post I've already tried this.

    I have even just tried setting to service protocol to only TLS 1.1 and 1.2 as per your example but still I get the below exception:
    System.Net.WebException: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. at System.Net.HttpWebRequest.GetResponse() at ...

    What else can we look at?

    Wednesday, June 10, 2015 5:36 PM
  • I just bit the bullet and ran a wireshark trace in production to see what's going on. Seems like our cipher suite order is NOT the one on https://msdn.microsoft.com/en-us/library/azure/dn775043.aspx. I will try to track down why this is the case. But here's what the client hello for your request would look like:

    As you can see there are no _ECDSA_ ciphers in this list, which is the only thing the server supports ... hence the server fails the TLS handshake. As I posted on the forums here, we are updating our cipher suites, and once we do this, your request will work. In the meantime, could you use a different server that uses more than just _ECDSA_ ciphers to test ssl, like ssllabs.com?

    Sorry for the trouble.

    Thursday, June 11, 2015 2:09 AM
  • Sadly I don't control the server my web app is connecting to, so I don't have any control over the cipher suits. Also, using SSL Labs isn't an option either. Guess I have no other option but to wait till the 18th July if I want to continue running my web app on Azure?
    Saturday, June 20, 2015 9:43 AM
  • Hello??
    Monday, July 6, 2015 7:00 PM
  • The change on July 18th is for our front ends for incoming TLS connections to your application. The issue you are seeing is for outbound TLS connections from your web app worker VM. Unfortunately the July 18th fix doesn't address the web app worker VM case, so it still won't work. I have a work item on my plate for fixing the issue on web app worker VM as well, but I don't have  timeline for the fix release. I will update this thread when I know more about when this will release. Sorry for the trouble.
    Monday, July 6, 2015 7:46 PM
  • So I was told to wait for July 18th and I'm being told this isn't going to work for an undefined period of time. I've had this issue for over a month and a half with no solution which means I cannot run my web application fully on Azure. This is really disappointing.

    I also know from stack overflow, I'm not the only one with this issue :(
    Monday, July 6, 2015 7:51 PM
  • It is really disappointing that this issue hasn't been resolved with Azure Web Apps/App Service after all this time.

    I'm pretty sure I've had this problem since 2015-02-06 when many of my outbound requests stopped working for Cloudflare proxied web sites, but most only failed with this error occasionally. In early April, I tried all sorts of hacky stuff to get it working again without success while it worked locally. It sounds like you've tracked down the problem which you've been able to do by getting on one of the Microsoft managed VMs.

    Ever since I've consistently got requests failing with this error occasionally, and I've got a few domains that just never succeed. Now that Cloudflare is being used by many more general personal and company web sites, I'm left with no choice but to leave Azure App Service.

    Monday, July 20, 2015 5:49 AM
  • Fitbit switched to using CloudFlare in front of api.fitbit.com on Thursday, July 30, 2015 at 00:10 PDT. We now have multiple customers using .Net and Azure who are experiencing difficult connecting to us. Any guidance on this issue would be very appreciated.
    Friday, July 31, 2015 6:45 PM
  • We will be deploying the fix in a couple of weeks to all regions. We will update this thread as soon as the fix goes out everywhere.
    Tuesday, August 11, 2015 4:46 PM
  • We will be deploying the fix in a couple of weeks to all regions. We will update this thread as soon as the fix goes out everywhere.

    Wondering if their is any update on this issue.

    We are facing similar problems though our AMS instance hosts a node js mobile app. Any attempt to make a https connection over TLS 1.1 / 1.2 with an external api is currently failing.

    The remote entity/server has a valid certificate issued by DigiCert.

    Thanks.

    Wednesday, September 9, 2015 5:31 PM
  • Any update on the fix?  Took me forever to track down this whacky problem.
    Thursday, October 1, 2015 10:57 PM
  • This is fixed and the fix is applied on all regions.
    Friday, October 9, 2015 10:00 PM
  • The issue is not resolved for us connecting to Fitbit.com which is behind CloudFlare.

    You can reproduce the issue by letting the following run continuously on your local dev machine OR on an Azure webjob. When the clock strikes XX:00 (a new hour) the first connection attempt will throw a WebException "The request was aborted: Could not create SSL/TLS secure channel."

    class Program
        {
            public static HttpClient httpClient { get; private set; }
    
            static void Main(string[] args)
            {
                Task.Run(() => MainAsync(args)).Wait();
            }
    
            static async Task MainAsync(string[] args)
            {
                httpClient = new HttpClient();
    
                while(true)
                { 
                    try
                    {
                        var result = await httpClient.GetStringAsync("https://www.fitbit.com");
                        Console.WriteLine(DateTime.UtcNow.ToString() + " Fitbit.com Content-Length:" + result.Length);
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine(ex.Message);
                    }
    
                    await Task.Delay(60000); //one minute
                }
            }
    
        }


    Saturday, October 10, 2015 12:13 AM
  • We will check this and get back to you as soon as possible.
    Saturday, October 10, 2015 12:24 AM
  • Aaron, what you describe seems like a very distinct issue. To clarify:

    Original issue:

    • All requests were failing when made from an Azure Web App
    • The same requests were succeeding from a non-Azure Windows client


    That original issue is what this thread tracks, and as far as we know, it is solved.

    New issue you bring up here:

    • It happens from all Windows client machines
    • Only fails when CloudFare rotates the TLS keys at the top of the hour


    So this new issue is no longer related to Azure Web Apps, and probably better discussed in a general .NET forum, where more experts can shine in.

    That being said, I did play with it quite a bit. I do repro the issue, and it looks like some kind of caching bug in .NET's SSL session caching logic.

    You can work around it using the technique described in this thread. The workaround is rather ugly, as it involved private reflection. But I did verify that it eliminates your issue. You'll have to decide if you want to go down that path.

    As a next step if you want to dig into this one deeper, please start a new thread in a .NET forum (e.g. this one or StackOverflow), and please post the link here so someone who lands here can track the follow up discussion.

    thanks,
    David


    Sunday, October 11, 2015 8:44 PM
    Moderator
  • Thanks David. Yes, it seems to be .NET framework related. But still maddening none-the-less. You're right, that's not really a great solution but I appreciate you digging in to it so we can get to some kind of real fix.

    For those wishing to follow me down the rabbit hole, here's the thread I just created for the .NET Framework folks. Hopefully by the time you click this there's an answer to the CloudFlare hourly cached bug here.
    https://social.msdn.microsoft.com/Forums/vstudio/en-US/eb999cd4-b43b-4779-b01b-4a04017714e3/httpwebrequest-ssl-caching-bug-cloudflare-the-request-was-aborted-could-not-create-ssltls?forum=netfxbcl

    --Aaron

    Monday, October 12, 2015 11:46 PM
  • I seem to have a similar issue as the first one stated in this thread. 

    Also getting "Could not create SSL/TLS secure channel" when connecting to a Server from my Azure Web Application. 

    If I run the application locally, it works. But not as soon as I run it on Azure. 

    I've run an ssllabs on the server that my app connects too:
    https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwebrepublic.com%2Fen%2F

    If the cipher list that you posted above is still correct, then they both should support at least  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. Connecting to other SSL servers works. Normally if they don't get as high a ssllabs grade as the webrepublic one. So I assume that means more SSL connection options.

    I has nothing to do with the Cloud Flare bug. This happens every time and they don't use Cloud Flare.

    I've tried all these things:

    ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
                            | SecurityProtocolType.Tls11
                            | SecurityProtocolType.Tls12
                            | SecurityProtocolType.Ssl3;                        

    But nothing helps.

    The app runs under .Net 4.6 and is a brand new Web Application instance. 


    • Edited by R. Blaettler Wednesday, December 23, 2015 1:51 PM
    Wednesday, December 23, 2015 1:50 PM
  • Can you try changing your client to only use TLS 1.2? Basically remove all the ORs from SecurityProtocol and explicitly set it to Tls12 alone. The top cipher on the server is definitely supported on the client. 

    If that doesn't work can you let me know your site name ... here's a guide on how to do that without posting it publicly. https://github.com/projectkudu/kudu/wiki/Reporting-your-site-name-without-posting-it-publicly

    Wednesday, December 23, 2015 7:05 PM
  • Cheers.

    I've tried that but it didn't help.

    This is the app:

    Breaks:

    http://webrepublic-com.aurebeshtranslator.net/en/

    Works:

    http://www-supertext-ch.aurebeshtranslator.net/

    It's basically a reverse proxy. So it takes the subdomain and replaces - with . and gets the content from there.

    Ignore the 404. Since it's an SSL error I don't seem to get a response object with a status code.

    But I put the error message into the status code description:

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

    SSL Labs for webrepulic:

    https://www.ssllabs.com/ssltest/analyze.html?d=webrepublic.com&latest

    Thursday, December 24, 2015 8:01 AM
  • Now that the holidays are over, any update on this? Is there a way to see where the mismatch happens? Or what ciphers Azure supports?

    Update: Found another Website where it does not work. They all seem to be nginx Servers.

    Monday, January 4, 2016 9:12 AM
  • I have the same issue on all of my Azure websites. Code that runs in Azure that connects to a site (e.g. using System.Net.WebClient) fails with "Could not create SSL/TLS secure channel" when that site is behind CloudFlare and also hosted in Azure. It's presumably some outbound/inbound SSL issue. The workaround, which is not ideal nor always an option, is to use the Azure "*.azurewebsites.net" version of my site URL.

    Unfortunately when using the Azure version of the URL is not an option I have no workaround and this is a huge issue for me.

    Here's two concrete examples, one where the workaround is acceptable and one where it is not.

    1) I host an ASP.NET WebAPI site in Azure that hosts REST endpoints for sending messages, let's call it https://www.mysite.com. This site is behind CloudFlare (so I can get free SSL with Azure). All of my other Azure hosted sites use this REST endpoints to send messages. Unfortunately they cannot interact with my site using https://www.mysite.com (could not create SSL/TLS secure channel), I must use https://mysite.azurewebsites.net. In the case the workaround is acceptable.

    2) I host an Azure WebJob that monitors the health of my sites by pinging them on a schedule. All of these sites are behind CloudFlare and HTTPS is forced via redirects and HSTS. On these sites I redirect all requests using the non-canonical hostname (www.mysite.com) to https://www.mysite.com, so requests to mysite.com and mysite.azurewebsites.net all 301 redirect to www.mysite.com. So in this case I cannot setup my WebJob to use the Azure URL because I ultimately need to access https://www.mysite.com which I cannot do.

    This is a critical issue for me and a resolution from Azure would be wonderful. Thanks

    Monday, January 4, 2016 5:38 PM
  • Ok interesting, I'm using .NET 4.5.2 and explicitly setting the protocol to use Tls12 does seem to work:

    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
    var client = new WebClient();
    var response = await client.DownloadStringTaskAsync("https://www.mysite.com/");
    I thought I was trying this but apparently not, regardless, no more SSL/TLS exceptions, thanks @Nazim

    Monday, January 4, 2016 6:42 PM
  • I'm running .NET 4.6 and I've tried that with only using TLS 1.2, but didn't help for me.

    Also I don't have the CloudFlare setup. Not sure if the client website does though.

    Tuesday, January 5, 2016 4:27 PM
  • I have the same problem. I am running an application on the Azure application Standard: 1 Small plan. Framework is 4.6.1

    I receive the same The request was aborted: Could not create SSL/TLS secure channel exception. On my local environment the applications runs without any issues.

    public async Task<List<QutationOverview>> GetAll(string url, DateTime lastActionDate)
        {
            var result = string.Empty;
    
            try
            {
    
    
                var userName = await _settingManager.GetSettingValueAsync("API.UserName");
                var password = await _settingManager.GetSettingValueAsync("API.Password");
    
    
                ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls |
                                                       SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
    
    
                ServicePointManager
                    .ServerCertificateValidationCallback +=
                    (sender, cert, chain, sslPolicyErrors) => true;
    
    
                //Add date filter
                //Always request qutations where the last action took place >= Yesterday
                var requestUrl =
                    $"GetALL/?last_action_date={lastActionDate.AddDays(-1).ToString("yyyy-MM-dd")}&format=json";
    
    
                var baseAddress = new Uri(url);
                var credentials = Convert.ToBase64String(Encoding.ASCII.GetBytes($"{userName}:{password}"));
    
                Logger.InfoFormat("GetAllQuotationsAsync for url {0}{1}", url, requestUrl);
    
                using (var httpClient = new HttpClient {BaseAddress = baseAddress})
                {
                    httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", credentials);
                    using (var response = await httpClient.GetAsync(requestUrl))
                    {
                        result = await response.Content.ReadAsStringAsync();
                        Logger.Info(result);
                    }
                }
            }
    
            catch (Exception ex)
            {
                Logger.ErrorFormat("GetAllQuotationsAsync {0}: {1}", url, ex);
            }
            var data = JsonConvert.DeserializeObject<List<QutationOverview>>(result);
    
            return data;
        }

    I also tried different version of the code (removed the validatecallback and just added TLS 1.2.

    Did anyone fixed the error?

    Saturday, July 16, 2016 5:02 PM
  • I am also facing the same issue since last evening with a client. The entire production is stuck due to this issue. We are calling a third party api that's working pretty well with php clients and even .net clients based on VM, but on webapp its this issue.
    Tuesday, September 20, 2016 3:10 PM
  • Hi,

         I using an azure API for android development with Xamarin. It's not working when I deploy the app. It throws the same error. But When I hit the API URI with the help of an console application it produces the result. Why I can't use the API when I compile it with the help of mobile device?



    • Edited by MJoseph_10 Tuesday, March 12, 2019 12:49 PM
    Tuesday, March 12, 2019 12:48 PM
  • MJoseph_10, since these issues might not be related, can you please start a new thread for your issue? Thank you for your understanding.
    Tuesday, March 12, 2019 5:16 PM
    Moderator