How do I fix a leaf certificate mismatch when connecting Azure App Gateway to an Azure Storage static website using a private endpoint?

The issue is that the TLS handshake is failing because the hostname in your App Gateway's backend settings (or probe) doesn’t match the Common Name (CN) in the certificate served by the storage static website (which is a wildcard certificate). Even though you’ve set up the private endpoint correctly, the certificate validation is still using the host header in the request to match against the certificate.

How to Fix

1. Override the Host Header
   In your Azure App Gateway’s backend HTTP settings, override the host header so that it matches the certificate’s CN.

   • For example, if your storage account’s static website is actually served over a hostname such as
     myaccount.z29.web.core.windows.net, then set the backend host header to that value instead of your custom DNS.
   • This ensures that when the TLS handshake occurs, the host header provided in the SNI matches the certificate being served.

2. Adjust the Probe Settings
   Ensure that the probe configuration in the App Gateway also uses the same host header override. Both the probe and the backend settings must have the same host header value so that they match the certificate details.

3. Validation
   You mentioned that accessing the private link endpoint directly works fine. This confirms that the endpoint itself is healthy and that the error is purely due to the host header mismatch in the TLS handshake.

Example Steps

• Go to the Azure Portal and open your Application Gateway.
• Under the Backend HTTP settings, select the HTTP setting used for your storage account.
• Find the option to Override with hostname and choose the option to "Pick host name from the backend target".
• Manually enter the correct hostname (e.g., myaccount.z29.web.core.windows.net) that matches the certificate’s CN.
• Repeat this configuration for the probe settings if you have a custom probe configured.

After making these changes, the TLS handshake should succeed because the SNI host header provided by the App Gateway will now match the certificate’s CN (even if it’s a wildcard).

Note

Changing the backend host header might be necessary because even though your DNS configuration maps your custom domain internally to the private endpoint, the certificate is still issued for the storage account’s public endpoint. Overriding the host header ensures the correct CN is presented during the TLS negotiation without having to disable certificate validation.

This approach maintains secure TLS validation while ensuring that the backend server’s certificate matches the expected hostname.