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 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.
So you get access logs from the start.
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.
You can use them anywhere, even outside Azure.
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.
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.
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.
For higher assurance you can ask Azure Key Vault to generate your key in HSMs.
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.
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
ou can create and deploy Web Apps using ARM templates or through UI. The following links describe how to do this:
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.
#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.
#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$policy = New-AzureKeyVaultCertificatePolicy -SecretContentType application/x-pkcs12 -SubjectName "CN=gowie.eu" -ValidityInMonths 12 -IssuerName $issuerName -RenewAtNumberOfDaysBeforeExpiry 60$certificateName = "CertTrial" #Name of the certificate object in your key vault; not related to subject name
Add-AzureKeyVaultCertificate -VaultName $vaultName -CertificateName $certificateName -CertificatePolicy $policyGet-AzureKeyVaultCertificateOperation $vaultName $certificateNameGet-AzureKeyVaultCertificate $vaultName $certificateNameOnce 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.
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.