Issue with SSL/TLS connection when calling token endpoint from within Azure

When using the Authorization Code grant, more times than often I find the following error in the logs:

Could not create SSL/TLS secure channel

My application is hosted on Azure. Any ideas on what might be causing this?

Here is the stack trace:

Message: The request was aborted: Could not create SSL/TLS secure channel.
Detail: System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
 at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
 at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)
 --- End of inner exception stack trace ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Auth0.Core.Http.ApiConnection.d__13`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Auth0.Core.Http.ApiConnection.d__11`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at .LoginCallback.d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at System.Web.TaskAsyncHelper.EndTask(IAsyncResult ar)
 at System.Web.HttpTaskAsyncHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult result)
 at System.Web.HttpApplication.CallHandlerExecutionStep.OnAsyncHandlerCompletion(IAsyncResult ar)

Unfortunately that’s one of those error messages that may occur due to a variety of reasons so it’s hard to pinpoint the cause just from the message itself. Excluding issues associated with self-signed certificates which do not apply to this case as the token endpoint provides a valid TLS certificate then this may be occurring by a mismatch between what the client has to offer in terms of support for SSL/TLS and what the server has to offer.

For example, the token endpoint if I recall correctly no longer supports SSL 3 and opts to go with TLS support. There’s a really long thread about this exact situation of outbound requests failing when they are initiated from Azure in the MSDN forums. If you haven’t done so already, you may want to go through it and try some of the suggestion, although I don’t think a definitive conclusion was reached.

In addition you may want to try to capture a System.Net trace of the error as it would likely give you additional information about the possible root cause. You can check this blog post that shows how to do this in an Azure App Service (Enable System.Net tracing on Azure App Service).

thanks for the response.

Ran the network trace. Here is what i found…I see the following right before the failed request with the error message ‘could not create…’

InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=BufferNotEnough).
following the…

On other successful calls…i see the following.
InitializeSecurityContext(In-Buffers count=2, Out-Buffer length=0, returned code=OK).

so is this something auth0 is fixing?

1 Like

Not sure if Auth0 can do anything…seems more like azure app service issue when trying to make 3rd party api calls…

Here is what i ended up doing…

  1. add the following in the LoginCallback before making the Auth0 api call for code exchange (‘ExchangeCodeForAccessTokenAsync’)
    ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
  2. Add re-try logic around ExchangeCodeForAccessTokenAsync. The call always succeeds the 2nd time.