This article is primarily intended to help in resolving problems with setting up end-to-end TLS for an Azure Application Gateway V2 when using self-provided certificates.
Version 2 of the Azure Application Gateway service provides a vast number of enhancements and new integrations with other Azure services, but this additional functionality comes with a number of changes in how the gateway is configured. One of these changes can affect how you set up TLS when fronting a backend application server pool that requires end-to-end encryption.
With version 1 Application Gateways, supporting a custom-signed backend SSL certificate was as simple as uploading the CA certificate in the Backend pool settings. When configuring an Application Gateway V2 instance, you will notice that the settings have changed somewhat; now, there are additional requirements for supporting certificates signed by a custom certificate authority. When trying to enable end-to-end TLS support, you might have come across this error:
Failed to save configuration changes to application gateway Error: Data for certificate is invalid.
Below is the solution to this problem.
The Backend settings in the V2 Application Gateway has this message displayed:
Trusted root certificate
For end-to-end SSL encryption, the backends must be in the allowlist of the application gateway. Upload the public certificate of the backend servers to this Backend setting.
Though the title says it all, it’s still kind of confusing due to uploads in 2 different areas as .pfx on listener and .cer under backend settings.
The field next to it asks if you want to use a Well Known certificate:
- If a certificate is signed by well-known CA authorities and if its CN matches the hostname in the HTTP backend settings, then it doesn’t require any additional steps for end-to-end TLS to work. You can just choose “Yes”.
- If the backend server certificate is self-signed, or signed by unknown CA/intermediaries, then to enable end-to-end TLS in Application Gateway v2, a trusted root certificate must be uploaded. Application Gateway will only communicate with backends whose server certificate’s root certificate matches one of the lists of trusted root certificates in the backend HTTP setting associated with the pool.
To start with, make sure you have extracted the full certificate chain from the .pfx file (which you have uploaded in the HTTPS Listener configuration) in Base-64 encoded X.509 /.pem format.
Note: Make sure, the same full certificate chain is deployed on the backend servers if you have a Web Proxy server like Nginx on the backend.
As in the image, Backend settings accept the certificate only if it is uploaded in .cer format. Here’s how you can convert a .pfx to .cer:
openssl pkcs12 -in cert.pfx -out cert.crt -nokeys -clcerts openssl x509 -inform pem -in cert.crt -outform der -out cert.cer
Once you have cert in .cer format, make sure to grab the root alone from the bundle and save it as a new file in .cer.
That’s it, now try uploading the newly saved .cer file.
Now your backend health should be green unless there are other configuration issues.
Here are a few items that could still report unhealthy backend:
- Missing Root certificate/Full certificate chain on the backend servers(Applicable only if you have Web Proxy server ex: Nginx)
- Make sure you have the health probe set correctly.
- Make sure that you have the Routing rules for both HTTP and HTTPS are configured correctly.
- Even though your backend health shows healthy, if your Application Gateway public IP doesn’t route to your backend by throwing a 502 Bad Gateway, then make sure you choose hostname override under the backend settings configuration and update it with the hostname the certificate is generated for.
You can also continue to explore the following article for more details on end-to-end TLS with V2 https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview#end-to-end-tls-with-the-v2-sku