Azure KeyVault – Authenticating with Certificates and Reading Secrets

April 17, 2017 By Introductions No Comments

You should never keep any confidential configuration information in an application configuration file. This include injecting sensitive information via web transformation files. Adding sensitive values via the AppService settings is not ideal either.

In all these cases you may leak sensitive information. For example via your source control. Or anyone with access to your subscription could get those secrets.

In a recent post we introduced Azure KeyVault as a solution for secure storage of confidential information. In this post we will take you through using KeyVault values in web applications.

There are two ways to authenticate a web application in KeyVault. You can store a simple client identifier and client secret in the app settings. This is a rather bad approach as it once again gives access to the KeyVault values.

A better is approach is to authenticate the web application using a certificate. This certificate is also deployed directly from KeyVault. This means neither the confidential information nor the keys to the vault are ever disclosed. This is why we choose this approach here.

There is one caveat though. In code you could still display the confidential information on a web page. Without code reviews this is still not a bullet proof solution.

Loading the access certificate for your application into KeyVault

You will be utilising the certificate store. So you must start a PowerShell in Administrator mode. Run all the following scripts in the same PowerShell session to retain the variables.

First we set some variables we are about to use.

The dnsName (and dummyurl) need only be unique in you subscription. They do not need to be real existing urls. The password is used when exporting certificates but you do not need it after the script has run.

Next you need to create a certificate which you then export to a file and remove the certificate from the store.

At the time of writing there is an issue with certificates created using PowerShell (i.e. New-SelfSignedCertificate). It seems to be an issue with the provider used by PowerShell (CNG – Cryptographic New Generation).

To solve this issue download OpenSSL and install it.

Next we use OpenSSL to convert the certificate to a compatible version and store is as a .pfx file.

If you are developing locally you need to install this certificate into your local store. Take note again not to use the Import-PfxCertificate cmdlet. It imports but using the certificate may lead to an “Invalid provider type” error.

Now you have the certificate as a base64 encoded string. You will now add an application to Azure Active Directory using it. For this application you can create a service principal. This in turn is used to give access to KeyVault.

Your application will use the certificate to authenticate against Azure AD. With this user (i.e. service principal) the application will access KeyVault. You need to make the certificate available for the web application. When running locally you have just imported the certificate to your local store.

In PowerShell run the following commands to retrieve the certificate thumbprint and application id. The latter is also known as client id. Both are used below.

In Azure we will store the certificate in KeyVault and deploy it to your application using ARM.

The resource definition to deploy the certificate is:

The name (webKvAccessCert) of the certificate needs to be unique per app service plan. If you are running this deployment more than once you may have to remove the certificate first. The deployment references the KeyVault by id. Use the name of the secret you used in the PowerShell above (kvAccessCert).

Important: If you have not already done so, give the WebApp-Resource Provider access to the vault. The ID is static across all of Azure:

In order for the app service to load the certificate you must add an app setting.

Use * to load all available certificates. Or you can use a comma seperated list of certificate thumbprints. Add this setting any way you’d like (ARM template, via portal or PowerShell). Make sure to restart the app service to load the application.

Using the certificate to access KeyVault

Install the following NuGet packages to use KeyVault from your application.

You can use the following helper class for reading the certificate and creating a KeyVaultClient.

Note that this is configured to search in the CurrentUser certificate store. This is where the certificates are loaded in Azure. Locally you may be importing them to the LocalMachine store instead.

If you are using .NET Core and do not want to use the provider shown in the next section, you need use the IClientAssertionCertificate interface instead and implement your own implementation.

Using the values you retrieved from PowerShell above you can create an instance of the client:

The last parameter is the key of the secret you want to retrieve. There are many moving parts to this approach. But using certificates deployed from KeyVault is the most secure approach.

You may run into errors such as:

Possible solutions are:

  • Make sure you don’t have hidden characters in your client id or thumbprint values from the copy paste. Either type them into a new notepad and copy that value. Or use a hex editor to check the string (e.g. Notepad++ with Hex Editor Plugin).
  • Make sure you have not create a new Azure Active Directory and added the application there. You must add the application into the default directory.
    If you come across any other errors and solutions, feel free to contact us.

Using Configuration provider

ASP.NET Core brings a new extensible configuration provider model. This allows for automatic loading of secrest from KeyVault.

Install the following NuGet Package

In your Startup.cs where the configuration is built add the following code:

It utilized the same two values (client id, certificate thumbprint) as the above code. Also note that you need to import your certificate to the right certificate store.

Microsoft provides a template class “EnvironmentSecretManager”. This class will only load secrest whose key begins with the application name.

This is by far the easiest way to inject configuration values from KeyVault to ASP.NET Core.