连接到 Azure Cloud Blob 存储失败，证书无效

Question

I'm using the Azure Storage Client Library to connect to my azure blob storage and publish some files. Following code is an extract of what I'm using to establish the connection and create a blob container:

var storageAccount = CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("settingsName"));

client = storageAccount.CreateCloudBlobClient();

var container = client.GetContainerReference("containerName");
            container.CreateIfNotExists();

This works fine on my local machine. However, if I try to run the exact same code on a different server I'm getting following exception:

Microsoft.WindowsAzure.Storage.StorageException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.GetResponse()
   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteSync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext)
   --- End of inner exception stack trace ---
   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteSync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext)
   at Microsoft.WindowsAzure.Storage.Blob.CloudBlobContainer.CreateIfNotExists(BlobContainerPublicAccessType accessType, BlobRequestOptions requestOptions, OperationContext operationContext)

Does anybody have an idea what could be causing this? I've been googling the problem for days now, without any solution.

Answer 1

This thread has been dormant for a while, but I recently ran across this same issue; I thought I would share my results in the hope that others may benefit from this in the future.

We were receiving the same error when attempting to write to an Azure Storage blob from a server, though the same code functioned fine locally and on other servers:

Microsoft.WindowsAzure.Storage.StorageException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

First, we verified that we had the proper certificate authorities installed on the machine. Often, this can be a culprit. However, in our case, we had all of the necessary certificate authorities.

What ended up being the issue was that the server was not resolving the proper IP address for the storage account (yourstorageaccountname.blob.core.windows.net).

Locally, try pinging your storage account from the command prompt, like so:

ping yourstorageaccountname.blob.core.windows.net

You should see that the ping from your local machine is able to resolve an IP address for your blob account (13.88.144.248, etc).

Now try pinging the blob account from your server, where you are getting this exception. If the ping is unable to resolve the IP address, or if it is resolving the wrong IP address (like in my case), you may have found your issue.

If this is the case, adding a simple mapping to the C:\\Windows\\System32\\drivers\\etc\\hosts file fixed our issue. If you are having the same issue, adding an IP mapping to the file should fix it. The mapping should map the IP from your local ping to the host name of your blob account. Here's an example:

13.88.144.248 yourstorageaccountname.blob.core.windows.net

Note that you will have to run your text editor (Notepad, etc) as Administrator to save the hosts file properly.

Answer 2

I have just encountered this error message accessing table storage during a unit test where I created a shim for DateTime.UtcNow .

This code has been used since at least 2017, so a recent package update must have caused this (using .NET Framework 4.8).