Self-Signed Certificate in Certificate Chain Error

There a few reasons you may be seeing this error, the two most common ones are:

  1. You are behind a “transparent proxy”, which means someone (such as your IT department) is intercepting HTTPS traffic, decrypting it, and then encrypting it using a self-signed certificate
  2. You are running software, such as anti-virus software, which is injecting a self-signed SSL certificates into the HTTPS messages you receive

When Storage Explorer encounters one of these “self-signed certificates”, it can no longer know if the HTTPS message it is receiving has been tampered with. If you have a copy of the self-signed certificate though, then you can tell Storage Explorer to trust it. If you are unsure of who is injecting the certificate, then you can try to find it yourself by doing the following:

  1. Install Open SSL
    • Windows (any of the light versions should suffice)
    • Mac and Linux: Should be included with your operating system
  2. Run Open SSL
    • Windows: Go to the install directory, then /bin/, then double click on openssl.exe
    • Mac and Linux: execute “openssl” from a terminal
  3. Execute s_client -showcerts -connect microsoft.com:443
  4. Look for self-signed certificates. If you’re unsure which are self-signed, then look for any where the subject (“s:”) and issuer (“i:”) are the same.
  5. Once you have found any self-signed certificates, then for each one, copy and paste everything from and including -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- to a new .cer file.

Open NotePad. Make sure, you are copying everything between —BEGIN CERTIFICATE— and —END CERTIFICATE— block. For example, if there are two certificates, then the file would be;

—BEGIN CERTIFICATE—

—END CERTIFICATE—

—BEGIN CERTIFICATE—

—END CERTIFICATE—

Save File as .cer on your computer.

  1. Open Storage Explorer and then go to Edit -> SSL Certificates -> Import Certificates. Using the file picker, find, select, and open the .cer files you created.

Resource;

https://github.com/CawaMS/StorageExplorerTroubleshootingGuide/blob/master/se-troubleshooting-guide.md#self-signed-certificate-in-certificate-chain

Azure Storage redundancy

Locally redundant storage (LRS) replicates your data three times within a single data center in the primary region. LRS provides at least 99.999999999% (11 nines) durability of objects over a given year.

The following diagram shows how your data is replicated within a single data center with LRS:

LRS is the lowest-cost redundancy option and offers the least durability.  If a disaster such as fir or flooding occurs with the data center, all replicas of a storage account may be lost or unrecoverable.

Zero-redundant storage

Zone-redundant storage (ZRS) replicates your Azure Storage data synchronously across three Azure availability zones in the primary region. Each availability zone is a separate physical location with independent power, cooling, and networking. ZRS offers durability for Azure Storage data objects of at least 99.9999999999% (12 9’s) over a given year.

The following diagram shows how your data is replicated across availability zones in the primary region with ZRS:

Microsoft recommends using ZRS in the primary region for scenarios that require consistency, durability, and high availability.

If your application is restricted to replicating data only within a country or region due to data governance requirements, you may opt for LRS or ZRS. The reason, In some cases, the paired regions across which the data is geo-replicated may be in another country or region.

Resource

https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy

How to Read blob file from Microsoft Azure Storage with .NET Core

In order to read a blob file from a Microsoft Azure Blob Storage, you need to know the following:

  • The storage account connection string. This is the long string that looks like this:
    DefaultEndpointsProtocol=https;
    AccountName=someaccounfname;
    AccountKey=AVeryLongCrypticalStringThatContainsALotOfChars==
  • The blob storage container name. This is the name in the list of “Blobs”.
  • The blob file name. This is the name of the blob inside the container. A file name can be in form of a path, as blobs are structured as a file structure inside the container. For ecample: folder/folder/file.extension

You also need this NuGet package:

Windows.Azure.Storage

The code is pretty simple:

using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Blob;
 
public string GetBlob(string containerName, string fileName)
{
  string connectionString = $"yourconnectionstring";
 
  // Setup the connection to the storage account
  CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);
   
  // Connect to the blob storage
  CloudBlobClient serviceClient = storageAccount.CreateCloudBlobClient();
  // Connect to the blob container
  CloudBlobContainer container = serviceClient.GetContainerReference($"{containerName}");
  // Connect to the blob file
  CloudBlockBlob blob = container.GetBlockBlobReference($"{fileName}");
  // Get the blob file as text
  string contents = blob.DownloadTextAsync().Result;
   
  return contents;
}

The usage is equally easy:

GetBlob(“containername”, “my/file.json”);