Manage certificates via Azure Key Vault

  • Article

Hello Friends!

I am excited to announce built-in support to create and auto-renew certificates for your cloud apps in Azure Key Vault.

Stay ahead of this very common problem

Every cloud app has app secrets – certificates, connection strings, encryption keys, etc. Unfortunately, managing these secrets effectively isn’t always easy and prone to mistakes if done improperly. Such a mistake has potential to cause a service outage, or credential leak, or process violation that shutter the business.

If you are a cloud developer, you must design your app to stay ahead of this. Azure Key Vault provides you the tools to do so.

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. The Azure App Service Certificates feature announced earlier this year was a big step towards that goal. 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.

Our customers’ scenarios however come in all shapes and sizes. So today we are announcing even more enhancements, built right into Azure Key Vault:

  1. You can now create your certificate and key in your key vault. So you get access logs from the get-go.
  2. As with earlier solutions, 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.
  3. There is no restriction on how you use the certificates. You can use them anywhere, even outside Azure.
  4. You now have a choice of certificate authorities to get your certificate from. We have started with DigiCert, and GlobalSign, and will add D-Trust shortly. We will continue to add other CAs; please check back again in a few months. This enables our international customers to get certificates from the CA required by their local regulations, and enables enterprises to get certificates from the CA that they already have an account with.
  5. 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.
  6. 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. Our API accommodates this workflow.
  7. For higher assurance you can ask Azure Key Vault to generate your key in HSMs. (This choice involves trade-offs. See the FAQ below to decide if this is the right choice for your scenario.)
  8. 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.
  9. And finally, because your certificate are in a key vault, you inherit all the other benefits Azure Key Vault offers, covered in earlier posts on this blog -- 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 etc

Three common scenarios where this feature really helps

  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.

The following are examples of when NOT to use this feature:

  • 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”.

Let’s look at one of these use cases end-to-end:

Let’s dive the first common scenario listed above (#1): Contoso builds an Azure Web app with a vanity domain and SSL certificate

Quick overview of the steps required
    1. Create an app with Azure App Service and configure it with a vanity domain.
    2. Create a key vault and a certificate object in it.

Here you have the following options:

    • Import an existing valid certificate into your key vault.
    • Create a self-signed certificate for testing purposes.
    • Create a key pair and certificate signing request (CSR) within your key vault and manually take this CSR to any public CA of your choice and get it signed.
    • Create a key pair and certificate signing request (CSR) within your key vault, and have Azure Key Vault request a certificate from a supported public CA
      Few things to note and take an action before selecting the last option:.
      • Create an account with the public CA that supports programmatic enrollment via Azure Key Vault. Skip this step if you already have an account.
      • Submit the domains for which you or your organization will request certificates. The CA validates this ahead of time so that when it is time for you to request a certificate the turnaround is quick (2-3 seconds). Periodically ensure you keep this up-to-date.
      • Your CA bills you per your account plan. The operations you do with Azure Key Vault are billed with your Azure subscription bill.

  2. Configure your app to the certificate URI in Azure Key Vault and perform the SSL binding.

  3. As long as your information with the public CA is up-to-date renewal requires no action from you. Azure Key Vault fetches the new certificate before your old one expires. The Azure App service platform picks up the renewed certificate automatically and does the SSL re-binding.

Here are more details on each step:

  1. Create an app with Azure App Service and configure it with a vanity domain You can create and deploy Web Apps using ARM templates or through UI. The following links describe how to do this:

  2. 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.We will cover a flow with PowerShell; but similar functionality is also available via the cross-platform command line interface or our SDKs and REST API.

    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 = "contosoKV"

    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 or go here to create one 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

    If you select GlobalSign to be your Issuer then go through these one-time setup steps to configure GlobalSign as one of the Issuer in your vault.

    Note: Customer will need to have an existing account or go here to create one with GlobalSign and get your domains pre-vetted

     #Create an administrator for the issuer (GlobalSign needs to receive Administrator details in the certificate request)
$firstName = "Patti"
$lastName = "Fuller"
$phoneNumber = "4250000000"
$emailAddress = "patti. fuller@contoso.com"
$admin = New-AzureKeyVaultCertificateAdministratorDetails -FirstName $firstName -LastName $lastName -PhoneNumber $phoneNumber -EmailAddress $emailAddress

#Create an organization for the issuer
$org = New-AzureKeyVaultCertificateOrganizationDetails -AdministratorDetails $admin

#Set the relation with the Public CA (GlobalSign) for cert issuance
$apiKey = "Passw0rd!"
$secureApiKey = ConvertTo-SecureString $apiKey -AsPlainText -Force
$accountId = "PAR1000_kvissuer"
$issuerName = "globalsign01"

Set-AzureKeyVaultCertificateIssuer -VaultName $vaultName -IssuerName $issuerName -IssuerProvider GlobalSign -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=contoso.com" -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

    Status will be completed once certificate enrollment has completed

     Get-AzureKeyVaultCertificateOperation $vaultName $certificateName

    Retrieve the certificate details

     Get-AzureKeyVaultCertificate $vaultName $certificateName

  3. 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.

  4. 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.
    Voila! You didn’t have to do anything to roll over the web app to use the renewed certificate.

  5. Wrapping Up:

    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.
    The Azure Key Vault SDKs in C#, Java, Node.JS as well as Azure CLI and Azure PowerShell have been updated with APIs/commands for the new certificates feature. The new .Net SDK is in preview. The CLI and PowerShell are generally available.

    FAQs

    Where is my favorite CA?
    We do understand that every enterprise has slightly different requirements which leads them to select a Certificate Authority. Azure Key Vault is working to get the popular CAs added. Drop us a note if you have any specific CA in mind.
    You can create the CSR (certificate signing request) within Azure Key Vault and then manually take it to their choice of CA, get it signed and then merge it back into your key vault. Azure Key Vault will still monitor the lifetime of your certificates and send an email reminder before expiry of your certificate to avoid disruption of service. Auto-renewal will be skipped until we natively integrate the CA into our workflow.
    Keep checking our blog as we may announce your favorite CAs in near future.

    How is this different from Apps Service Certificate support for GoDaddy?
    In the App Service Certificate scenario the focus is very similar to common industry wide solution of solving enrolling for SSL certificates in minutes based on the assumption that the domain owner and app developer are the same entities and Domain Validated certificates are good enough for the web apps.
    This release complements it. Our initial focus is on OV and EV SSL certificates. We will merge these into one workflow in the future.

    Will there be any charge for Key Vault certificates?
    Please check with your Certificate Authority regarding what they charge for certificates. In addition Azure Key Vault charges a transaction fee as listed here.

    How soon are certificates issued via Azure Key Vault?
    The certificates are generally issued within 2 to 3 seconds of the certificate request as long as your information with the CA is up-to-date. The domains which are included in the certificates have to be pre-vetted by the Public CAs which takes 2 to 3days, so we recommend you do this ahead of time.

    Can I request certificates other than SSL?
    Azure Key Vault certificate policy can be used to set the relevant EKUs and accordingly create a certificate signing request and get it signed by a CA or self-sign it. Currently the scenario has been mainly optimized for SSL certificates.

    Can I get certificates for multiple domain names (SAN certificates)?
    Azure Key Vault certificate policy can be set to include SAN (DNS names) and accordingly send it to the CA.
    Is the key that backs my certificate bound to HSMs in the Key Vault service?
    When generating your CSR, you have the option to specify that the key pair be generated as non-exportable and generated inside an HSM. If you do this then you cannot distribute your certificate and private key to your app nodes as illustrated in the end-to-end flow example above. Instead you must use software that can terminate TLS with a remote key in a key vault, such as Brocade’s Virtual Traffic Manager. Your app will be subject to throttling limits on Azure Key Vault. Use this option when isolation of your key is more important than scalability of your application or the latency of your TLS transactions.

    Terminology

    Public CA (Certificate Authority)
    Certificate authority or certification authority (CA) is a trusted entity that issues digital certificates. Major browsers and devices include the CAs that they trust.
    Domain Validated Certificate
    These are SSL/TLS certificates contain domain names which are confirmed via email sent to the domain owner listed in the domain registration database (WHOIS). There are also other ways to confirm the domain ownership. e.g. owner can prove ownership by uploading a file on the website. Either method confirms that the party requesting the certificate is in control of the domain.
    Organization Validation certificates (OV):
    CA will rigorously verify the actual organization that is attempting to get the certificate and also that the organization rightfully owns the domain. The organization’s name is also listed in the certificate, giving added trust that both the website and the company are reputable. OV certificates are used by enterprises, governments, and other entities to provide an extra layer of confidence to their online visitors.
    Extended Validation certificates (EV)
    Extended validation certificates are the certificates where highest level of validation was conducted by a Certificate Authority to ensure the domains in the certificates are owned by the organization requesting the certificate. It uses the highest standards of assurance to establish the legitimacy of online entities and confirm their authenticity and ownership of the domains in question. High visibility consumer websites use EV certificates. Browsers show trust in these using indicators such as a green bar.

    Comments are disabled, head over to the Azure Key Vault forum to discuss about this blog