Manage certificates via Azure Key Vault

The certificates feature of Azure Key Vault provides lifetime monitoring of strongly validated SSL certificates along with private key protection in an enterprise environment where domain owner and app developer are different entities. It is a win-win approach from security as well as ease perspective.

How does Azure Key Vault help?

The goal of Azure Key Vault’s secret management features is to eliminate manual steps in the flow of cloud app secrets. It gives you a domain-validated TLS certificate, keeps it renewed automatically to avoid outages, and stores it in your key vault, so that you can then distribute it to applications that integrate with Azure Key Vault.


New features / benefits

Create your certificate and key in your key vault

So you get access logs from the start.

Azure Key Vault will renew your certificate automatically where possible

It will also notify you, in case there are manual follow-ups required to complete the renewal. This reduces the chances of an outage in your cloud app.

There is no restriction on how you use the certificates

You can use them anywhere, even outside Azure.

You have a choice of certificate authorities to get your certificate from

Microsoft have started with DigiCert, and GlobalSign, and will add D-Trust shortly. International customers can get certificates from the CA required by their local regulations, and enterprises can get certificates from the CA that they already have an account with.

Organization Validation (OV) or Extended Validation (EV) certificates

Through these certificate authorities, you can get Organization Validation (OV) or Extended Validation (EV) certificates, which provide higher level of trust compared to domain validated certificates that prove just the ownership of the domain.

API accomodates seperation of duty workflows

Some organizations, especially enterprises, have a central team that manages domains for the organization, and/or a central billing account with CAs. This team is often separate from the teams that deploy apps with TLS certificates. Both parties must participate in getting a TLS certificate.

Azure Key Vault can generate your key in HSMs

For higher assurance you can ask Azure Key Vault to generate your key in HSMs.

Manage all your application secrets in one place

You get to manage all your application secrets – these certificates as well as connection strings, passwords, storage keys etc – in one place, your key vault(s). The first step in reducing mistakes in handling secrets is to know what secrets you have. Centralizing their management helps with that.

Inherit all the other benefits Azure Key Vault offers

distribute certificates using the built-in support in Azure VMs, VM scale sets, Web Apps (App Services), Service Fabric clusters/apps; get usage logs, analytics, and alerts via Azure Application Insights and Operations Management Suite


Common scenarios

  1. You have a web app built on the Azure App Services platform. Your app needs an OV/EV TLS server certificate, and you need to keep it refreshed before it expires. You generate your certificate in a key vault and connect your web app with it. Azure Key Vault automatically renews it. The App Services platform automatically picks up new certificates to keep your web app up at all times.
  2. You have an app that runs across hundreds of Azure VMs and needs a client authentication certificate. If you embed the certificate into your VM image you not only run the risk of theft at rest, but also every time you need to update the certificate you need to update the image and redeploy hundreds of VMs. Instead you generate your client authentication certificate (perhaps a self-signed certificate) in a single key vault, register it wherever you need to, and then push the certificate into your 500 VMs at runtime.
  3. You decide to take your cloud app through SOC / PCI / FedRAMP / ISO certification. The auditor asks you to show evidence that you roll your TLS certificates (and other app secrets) regularly, evidence that you know where that certificate goes, and evidence that you know who has access. You generate all this evidence from your key vault.

When NOT to use

  • Your cloud app stores data provided by your customers, and that includes certificates. You are on the hook to just store them securely, not to manage them. In this case store them with the rest of your customer data in Azure Storage/SQL or other general purpose storage, with encryption turned on. Let your customer manage the lifecycle of their certificates as they may have their own requirements for secrets management.
  • Your cloud app has several thousand users, and your cloud app generates and distributes Wi-Fi certificates to those users’ devices. Such certificates are not part of your app configuration and aren’t “app secrets”. Issue them from a CA designated for that use, and store them in a general purpose store with encryption turned on. Key Vault is for “app secrets”.

How To

Walk-through

Create an app with Azure App Service and configure it with a vanity domain

ou can create and deploy Web Apps using ARM templates or through UI. The following links describe how to do this:

  • https://azure.microsoft.com/en-us/documentation/services/app-service/web/
  • https://blogs.msdn.microsoft.com/appserviceteam/2016/05/24/deploying-azure-web-app-certificate-through-key-vault/

Create a key vault and a certificate in that key vault

There are four options available here as mentioned above. Look at the next blog post ‘Getting Started with Azure Key Vault Certificate’ on how to do each of these four options.

We will look at the most interesting one which is to request a certificate programmatically from one of the supported public CA’s. In this option you need an account with one of the supported CAs, and you need a credential from that account for the domains for which you will request a certificate. In some organizations a central team manages domains and billing, so we made our flow generic to accommodate this.

Go to PowerShell, login to Azure account, set the correct subscription context, and create a key vault. If you have never created a key vault with PowerShell please follow ‘Get started with Azure Key Vault tutorial’.

#Set this to the name of the key vault that you just created
$vaultName = "GowieKeyVault"

Azure Key Vault goes on behalf of the user to enroll for certificates from one of the above issuers. In this process Issuer needs to authenticate the entity requesting the certificate and also authorize to issue the requested certificate. Each Issuer requires different set of information to do so and this needs to be set once in the key vault.

If you select DigiCert to be your certificate authority or Issuer to issue certificates then go through these one-time setup steps to configure DigiCert as one of the Issuer in your vault.

Note: Customer will need to have an existing account with DigiCert and get domains pre-vetted

#Create an organization for the issuer
$orgIdentifier = "111111"
$org = New-AzureKeyVaultCertificateOrganizationDetails -Id $orgIdentifier

$apiKey = "111111111"
$secureApiKey = ConvertTo-SecureString $apiKey -AsPlainText -Force
$accountId = "1111111"
$issuerName = "digiCert01"

#Set the relation with the Public CA (DigiCert) for cert issuance
Set-AzureKeyVaultCertificateIssuer -VaultName $vaultName -IssuerName $issuerName -IssuerProvider DigiCert -AccountId $accountId -ApiKey $secureApiKey -OrganizationDetails $org

Create a certificate policy. This is a template that defines what needs to be in the certificate (SubjectName, SAN etc.), when to renew the certificate, and which CA to get it issued from.

$policy = New-AzureKeyVaultCertificatePolicy -SecretContentType application/x-pkcs12 -SubjectName "CN=gowie.eu" -ValidityInMonths 12 -IssuerName $issuerName -RenewAtNumberOfDaysBeforeExpiry 60

Kick off the enrollment process

$certificateName = "CertTrial" #Name of the certificate object in your key vault; not related to subject name
Add-AzureKeyVaultCertificate -VaultName $vaultName -CertificateName $certificateName -CertificatePolicy $policy

Since this is a remote call, it may take time. Check the enrollment process status periodically.

Get-AzureKeyVaultCertificateOperation $vaultName $certificateName

Retrieve the certificate details

Get-AzureKeyVaultCertificate $vaultName $certificateName

Configure your app to use the certificate from your key vault for SSL

Once the certificate is enrolled and stored within your key vault, the developer uses the steps on the following page to deploy the certificate to your web app and perform SSL binding.
https://azure.microsoft.com/en-us/documentation/templates/201-web-app-certificate-from-key-vault/
Observe that all you can continue to use the same deployment scripts you had earlier with Azure Key Vault. That is because for every Azure Key Vault Certificate, there is a corresponding secret and a key is created. Hence, if you delete the secret and create a certificate with the same name which will create a corresponding secret of the same name. The scripts would work as intended.
Certificate endpoint only returns the public portion of the certificate. Secret endpoint provides the access to private key of the certificate. This also enables Contoso to give only the application to have private key access i.e. the secret endpoint and the developer/operators could have access to the public information i.e. certificates endpoint which also just the management endpoint to add and remove certificates.

Certificate renewal

When it is close to the expiry time of the certificate, Azure Key Vault attempts to renew the certificate from the public CA. It also sends an email to the contacts listed in the certificate object before and after the renewal.
The Azure App Services platform periodically polls your key vault to check if there is an updated certificate. If it finds one it reads the new one and rebinds SSL/TLS for your app.