Some fun with Azure Key Vault REST API and HttpClient – Part 4.1

I thought I would have a new title for this article as it is not going to cover the use of HttpClient and Key Vault REST API. Spent a little bit of time thinking, I decided to let it be part of the series to show you a few funny things around Azure Key Vault certificate in a secret store. Don’t mind the version 4.1 as it’s just a number!

This article somewhat covers scenarios and biased reasons as to why you might need to store your certificates to Secret store instead of Keys or Certificates. It also shows a proof that my certificate’s password was stripped which would potentially results to security threat.

Keep track of the series:

When to use certificate as a secret?

Once again, Azure Key Vault is designed to answer for several questions regarding cryptographic management. For example, you may ask if you can build an application that integrates with Key Vault for encryption and signing. Or you may ask if Key Vault can help to ‘mask’ your API key so you don’t need to explicitly declare it somewhere in your application.

A common scenario in which a certificate is uploaded to a secret store is when you would like to host it for another system to read to. There is not any signing, encryption process that is powered by Azure Key Vault. For example, the certificate is used for Application Gateway. In fact, it is not available as of this article to have such an integration but have you had a look at this feedback? The store would not be Keys or Certificates, it is Secret!

Also from the feedback above, you know that people are still ‘interested’ in deploying an SSL certificate into secret store and web app in Azure App Service would just calls to a secret identifier and unpack things inside that SSL certificate. Even from one of Microsoft’s articles, there is a need of certificate as a secret. It says that instead of adding a certificate inside your web application, use Azure Key Vault secret to store your certificate. You would also like to implement SSL-offloading in which Azure Key Vault secret is a main gateway for SSL termination.

There might be more reasons to deploy a certificate as a secret to Azure Key Vault. Anyway, you have their own reasons. Have you ever been aware that if your *.pfx certificate is compromised, it is still safe? It is if that certificate has password protected during the creation. An an unauthorized person who has that certificate cannot use it for further attack if he doesn’t have a password to open and install it. At least, he needs to perform brute-force techniques to guess the *.pfx password and the time needed depends on the password length and complexity.

If you are not aware, meaning you completely trust Azure Key Vault in this case. You think that your password-protected certificate hosted in a secret store is safe even when you download it, you still need to provide the password. You should be worried right now because this is not the default behavior in the past.

What is allowed now?

Before I show you that a password-protected certificate in secret store does not need password to be installed, let’s have a look at the available option currently. First, you are no longer allowed to upload a password-protected certificate in Azure Key Vault as a secret anymore. “This feature has been deprecated” means it used to be an encouraged option. You are suggested to upload to Certificate store in Azure Key Vault.

Via Part 4, you can upload a password-protected certificate programmatically over Azure Key Vault REST API. I’m unsure how to prevent this way because the value passed to is Based64 encoded string. And when you successfully provision a certificate as a secret in Azure Key Vault with correct application type, you are given the ability to download as a certificate. Guess if this certificate requires a password before being installed? Yes it is! Why should you still worry?

My past certificate’s password is stripped

Fortunately, I have some past *.pfx certificates to actually show you that my certificate’s password was stripped. Before showing something, I’d like to indicate two references (might be more but privately reported) that folks ask for certificate password so you don’t think that I just invent something

First, let’s retrieve the value in my *.pfx certificate and write all the Base64 encoded string to a *.txt file.

public static async Task<string> GetSecret(HttpClient client)
    string url = $"/secrets/cert/0ba9355f795e490b93c5c23ba74d826c?api-version=2016-10-01";
    string filePath = "D:\\encodedbase64.txt";
    using (var response = await client.GetAsync(url))
        JObject responseCon...tent = JObject.Parse(await response.Content.ReadAsStringAsync());
        string encodedBase64 = responseContent["value"].ToString();
        File.WriteAllText(filePath, encodedBase64);
        return encodedBase64;

..and now convert and write bytes to *.pfx file using PowerShell.

$base64 =  Get-Content "D:\encodedbase64.txt"
$file = "D:\awesomepf-nopw.pfx"

$bytes = [Convert]::FromBase64String($base64)
[IO.File]::WriteAllBytes($file, $bytes)

This is a raw file and a no-password-protected *.pfx file I uploaded into public repo so you can get it to test yourself. The *.pfx file I uploaded was downloaded directly from that secret so the naming convention remains intact with format <key_vault_name>_<secret_name>_<date_downloaded>. You can try yourself with the extracted Base64 encoded string from GitHub. This certificate was directly uploaded via Azure Portal.

A new certificate’s password is not stripped

I don’t know when the fix was done, the above certificate was upload on Feb, 22 2018. On this day, I asked in a private MVP communication channel about the concept behind stripping password of my certificate but haven’t received any response so far. I then worked out  another *.pfx certificate shown in the below screen:

The *.pfx certificate I uploaded yesterday on Feb 23, 2018 requires a password before the installation. Here is the raw file. The debugging screen below shows you my certificate.

Testing to see if this *.pfx file requires a password to open can be done simply by the following PowerShell

Get-PfxCertificate -FilePath "D:\awesomepf-api.pfx"

What would you think about this password stripping? Does this matter to your environment?

Thought on password stripping

From what have been demonstrated, it seems that Azure Key Vault silently used to strip password of the certificate we set to protect. I don’t know any concept and reason behind this, but without password protection, I’d say my certificate which contains private key is insecure. A potentially case when someone manages to download your certificate and uses it for further elevated attack (e.g. signing or decryption to gain more sensitivity), he doesn’t need a password.

It’s been 2,5 years since the announcement of Azure Key Vault public preview. For that enough long, I don’t know how many organizations have been uploading certificates into secret store, and also am unsure if there is any awareness on this matter. In large environments where many IT service providers get engaged, with enough permission there is no guarantee that your certificate is safe enough. An assumption given to a compromised developer workstation which results to a non-password-protected certificate which is being used for VPN, then you should know how hard to control when a private network is accessible.


Patching means you no longer trust your certificates stored in Key Vault secrets and you need to find an approach to remediate the issue. While creating new vault will result the system downtime due to changed vault identifier, you can create new version for all affected secrets then change the version in your application’s configuration in case versions are specified. Otherwise, the application will retrieve the latest version. To test, you need to export your *.pfx and try to recursively import to CurrentUser store with password parameter passed through. Any certificate without password will throw an exception.

static void Main(string[] args)
        X509Certificate2 certificate = new X509Certificate2("D:\\exported-custom-cert-nopw.pfx", "123456");
        X509Store store = new X509Store(StoreName.TrustedPublisher, StoreLocation.CurrentUser);
    catch (Exception ex)

You are also recommended to use Certificate in Key Vault instead of Secret. In Certificate, you can download the .*pfx file with appropriate permission. The return of getting information of a specified certificate via REST API only gives public part (.cer) of the *.pfx file. But, the password stripping still persists. It means you really need to have a good Key Vault governance with appropriate access policies (e.g restricting List permission to secrets or certificates to developers).


This articles does give you information about password stripping. If this article is wrong with careful research or inadequate  level of knowledge resulting false positive, I’m very happy to be educated and receive feedback from security experts, especially those who work on the Azure and other certificates.

I also uploaded two pairs of certificate and raw data in GitHub so you can test yourself.

This entry was posted in Secure Development. Bookmark the permalink.

2 Responses to Some fun with Azure Key Vault REST API and HttpClient – Part 4.1

  1. Pingback: Some fun with Azure Key Vault REST API and HttpClient – Part 2 | All about security on Microsoft Azure

  2. Pingback: Some fun with Azure Key Vault REST API and HttpClient – Part 4 | All about security on Microsoft Azure

Leave a Reply

Your email address will not be published.