Michael Howard 3:39 am on April 29, 2021  

The Relationship Between Keys, Secrets and Certificates in Azure Key Vault

I decided to write this post based on some customer confusion when using Azure Key Vault. I hope this can help put a little more visibility into how Azure Key Vault (AKV) works.

AKV is an Azure Platform as a Service (PaaS) technology that can store and manage secret data in a secured and audited environment. It is a critical component of every solution I have worked on in the last few years. The general rule of thumb for storing any secret data in Azure is to use Key Vault.

Please note, there is another service named Azure Key Vault Managed HSM. I won’t get into the specifics about this new product. That’s a topic for another day.

AKV can store three distinct data types:

  • Keys
  • Certificates
  • Secrets

Let’s look at each in a little detail.

Keys

A key in AKV is either an RSA key or an Elliptic Curve (EC) key which are both asymmetric algorithms. Asymmetric means there’re two keys: a private key and a public key, the two are mathematical related but you cannot deduce one knowing the other.

The screen shot below shows the two key types RSA or EC and the fact that you can opt to store the keys in hardware (HSM keys, Hardware Security Module) rather than software.

Figure 1 Creating a Key in Key Vault, note there are two algorithm types – RSA or EC and two storage types HSM (Hardware Security Module) and non-HSM

AKV can perform various cryptographic operations within AKV such as encrypt/decrypt and sign/verify using RSA/EC keys. There is a subtle nuance about some operations and you can read about that topic in a previous post.

Certificates

Certificates are X.509 v3 certificates and associated private keys. Remember, the public key is in the certificate. The job of a certificate is to bind a name to a public key.

Note, you can’t store JUST the certificate, you must include the private key, too. When importing a certificate and private key, the most common data formats are PEM and PKCS 12. PKCS 12 and Microsoft’s PFX are the same format so if you’re having an issue importing a .P12 file into AKV in the Portal, just rename to file to .PFX and you should be good to go.

Secrets

A secret is anything that’s sensitive that’s not an asymmetric key or a certificate, such as:

  • An 256-bit AES symmetric key
  • A database connection string
  • A Kubernetes secret
  • An Application token

It’s important to point out that you can store AES keys in Key Vault, but they are really just a series of bytes, AKV doesn’t know they are AES keys.

If you look at the list of actions you can perform that apply to secrets, there’re no cryptographic operations that can be performed by AKV. Take a look for yourself here. No crypto operations. Now look at the list of operations for Keys, and you’ll see a number of crypto operations such as decrypt and sign.

So we’ve covered all three data types that can be stored in Key Vault: keys, certificates and secrets.

As noted, a certificate is really two items – a certificate and a private key.

Now here’s the fun part. When you store a certificate, the Key Vault Portal experience will only show the certificate. You can try it yourself. Head over to the Azure Portal, create a Key Vault and then create a self-signed cert (yes, I know, I know… never use self-signed certs! But we’re testing something here, not deploying certs in production!)

Once the cert is created, you’ll notice the cert listed under Certificates, but there is nothing shown under Keys nor Secrets.

Heads up, we’re using the Azure CLI from now on. More info here Manage Azure Key Vault using CLI – Azure Key Vault | Microsoft Docs.

Now go open an Azure CLI, and use the az keyvault certificate show command (az keyvault certificate | Microsoft Docs). For example, for my certificate, I used:

az keyvault certificate show --id https://xyzzy42.vault.azure.net/certificates/testcert/d60ac807d99d4743bbe51f23b10edff9

This outputs a bunch of really interesting data:

Figure 2: Output of az keyvault certificate show

I want to point out a few data items.

  • cer is the base-64 encoded certificate.
  • kid is the URL to the private key associated with this certificate.
  • sid is the URL to the public key held within the this certificate.

So now that we have the URL to the public key (it’s in the sid variable), we can view it using az keyvault secret show command (az keyvault secret | Microsoft Docs). Technically, the public key is not a secret, but I guess the data has to go somewhere!

Figure 3: Public key data

We can also use az keyvault key show (az keyvault key | Microsoft Docs) to get to the private key info:

Figure 4: Private key data

You can also use PowerShell to access KV data, using cmdlets like get-azkeyvaultkey (Get-AzKeyVaultKey (Az.KeyVault) | Microsoft Docs) and get-azkeyvaultsecret (Get-AzKeyVaultSecret (Az.KeyVault) | Microsoft Docs).

Summary

A certificate in Key Vault is not just a certificate, it must be a cert AND the associated private key. The certificate is accessible in the Certificates collection in the Portal UI. The private key and the public key are not exposed in the Portal UI, but they are exposed via the REST API, usually using the Az CLI or PowerShell or even custom code calling into the REST APIs.