How do I use a private dns zone or custom record or private IP to connect to Azure Key Vault and Azure Storage with https over private endpoint?

Question

This question applies to both Azure Key vault and Azure Storage, but I'll be demonstrating with just the key vault to give a tangible example.

I have a node app running on a VM and another in a Container Apps environment. I want to grant them the ability to communicate with vault so I created a private endpoint and have the my-vault.vault.azure.net url associated with a private ip 10.100.10.123 within my subnet. Using the SecretClient from @azure/keyvault-secrets, I am able to successfully fetch a secret by passing the url (https protocol) into the client's constructor. Providing https://10.100.10.123 fails, however, because of the IP/host mismatch - which is to be expected. I also have a private DNS Zone and all of the other url's I'm using are using the format sql.stage.app.io. I would like to alias the vault URL with a CNAME record to be vault.stage.app.io OR connect directly via the IP address, but I still get the IP/host mismatch error. All traffic is originating in my virtual network and is safe.

Is there a way to make this work?

Answer 1

@awf09j

Thank you for reaching out.

Based on your response above

Configuring the .io address to alias the vault.azure.net still ends up with the hostname mismatch error. The cert only contains the latter, not must custom domain. Isn't this by design for HTTPS? Am i missing something?

Yes, your deduction here is correct. This is a limitation by design. When you send a HTTPS request to the KeyVault the HostName should match <your_keyvault_name>.vault.azure.com in order to successfully complete the TLS handshake. Even when you added the CNAME for <your_keyvault_name>.vault.azure.com in your stage.app.io DNS zone the https request to vault.stage.app.io will still throw the IP/Host mismatch error as the hostname will not match with the TLS certificate of the KeyVault service. Currently it is not supported to onboard a custom domain with HTTPS support for Azure Key Vault.

If you wish to add this as a feature to Azure Key Vault. Please feel free to file feedback on our feedback portal.

Hope this helps! Please let me know if you have any additional questions. Thank you!

---

​​Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

Answer 2

Hi Awf09j,

It's important to understand that the Azure Key Vault service relies on the hostname (DNS name) provided in the URL to verify the endpoint's identity. When you create a private endpoint and associate it with a private IP within your subnet, you are essentially telling Azure to route traffic to that IP address when accessing the Key Vault service at "my-vault.vault.azure.net." The Key Vault service expects to see that DNS name in the request for hostname verification.

When you attempt to access the Key Vault service using an IP address (e.g., https://10.100.10.123), the service checks the request's Host header (or the IP address used in the URL) against the DNS name associated with the Key Vault, and if they don't match, it will trigger a host mismatch error.

To work around this issue, you have a couple of options:

Use a CNAME record: As you mentioned, you can create a CNAME record in your private DNS zone to alias "vault.stage.app.io" to "my-vault.vault.azure.net." This allows you to access the Key Vault using a custom domain name, which is recommended for such scenarios. You will need to ensure that the CNAME record points to the DNS name of the private endpoint.

Configure your application to use the DNS name: Instead of accessing the Key Vault via an IP address, configure your application to use the DNS name directly (e.g., "https://vault.stage.app.io"). This will match the DNS name associated with the private endpoint, and you won't encounter the host mismatch error.

It's generally a best practice to use DNS names and CNAME records for accessing Azure services, as it provides flexibility and ease of management. IP addresses can change, and using DNS names allows you to abstract the underlying infrastructure details. If you choose to use IP addresses, you would need to manage these IP addresses and DNS name associations carefully, as any changes in the Azure infrastructure may lead to issues like the one you described.

Thank You!

Answer 3

This is one of the many misses from Microsoft, and hoping they eventually fix this issue. There are many use cases, especially in Enterprise environments, where handing out the vault.azure.net domain name is a non-starter. Thus Key Vault cannot be used in these instances, and another non-Microsoft product must be selected instead.