Delen via

generating self-signed certificates with keyvault

  • Artikel

Thankfully it is very easy to import pre-existing self-signed certificates into KeyVault.  But... what if you don't have a pre-existing self-signed certificate?

It is possible to have KeyVault generate the new self-signed certificate for you inside of your KeyVault.  One and done.  No import. No messy certificate residue left behind at your admin console.

The trick to getting KeyVault to do this for you is to use "Self" as the issuer name in your policy file.  

Here is a simple example of how to generate the self-signed certificate using the Azure CLI:

 azure keyvault certificate policy create --issuer-name Self --subject-name "CN=www.contoso.com" --file policy.json --validity-in-months 12
azure keyvault certificate create --vault-name mykeyvault --certificate-name mycert --certificate-policy-file policy.json

Here is an example of how to do it using Powershell (as found in the Quick Start document below):

 $policy = New-AzureKeyVaultCertificatePolicy -SubjectName "CN=www.contoso.com" -IssuerName Self -ValidityInMonths 12
Add-AzureKeyVaultCertificate -VaultName $vaultName -Name $certificateName -CertificatePolicy $policy

If you want to dive deeper, or if what you really want is a full fledged SSL certificate created in similar fashion, here is some more documentation:

Comments

  • Anonymous
    August 22, 2017
    I got below error when create the certificate, but I've signed in using a ServicePrincipal not an actual user, have you seen this problem and resolved it?error: AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user's session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com).
    • Anonymous
      March 30, 2018
      I haven't seen this particular error, but I have run into situations where I wanted to use a service principal rather than a user account, and performing certain operations with key vault became more difficult because the service principal did not have the permissions it needed by default. I came across the following section labeled "Assigning Permissions" in the following blog article by one of our MVP's that may be useful to set these permissions: https://dscottraynsford.wordpress.com/2017/04/17/using-azure-key-vault-with-powershell-part-1/