The Common Name of the leaf certificate presented by the backend server does not match the Probe or Backend Setting hostname of the application gateway.

Question

Hi All

Listener type - Multi site, Host type - Multiple/wildcard, Hostname is *.domain.com it's working properly for HTTP and connect to the appropriate site in the backend pools, but for HTTPS listener it's failing, below are my configuration.

In HTTP: Reachable the backend site

---

site01.domain.com -> appgw listener-http(*.domain.com) -> backend setting (Override with new host name:no) -> backend health is fine -> backend VM IIS(site01 binding).

In HTTPS: unreachable to backend site.

---

CN of wildcard certificate is *.domain.com, we have more than 50 site running like site01-site50.domian.com

https://site01.domain.com -> appgw listener-https (*.domain.com) -> backend setting (Override with new host name:no) -> backend health is failing

https://site01.domain.com -> appgw listener-https (*.domain.com) -> backend setting (Override with new host name:yes, Override with specific domain name hostname *.domain.com) -> backend health is failing

Health Probe Not able to create with *. getting error (This value is neither an IP address nor a fully qualified domain name (FQDN).)

I also checked the link https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-health-troubleshooting#backend-certificate-invalid-common-name-cn

I have attached the screen shot of Appgw listener, backend setting, backend setting health, health probe in PDF format.

could you please guide me, how i can fix this issue.

Thanks

Veera.

appgw-confgiguration.pdf

Answer 1

Hello @Veera ,

I understand that you are getting the following error when trying to setup your Application gateway listener to HTTPS - "The Common Name of the leaf certificate presented by the backend server does not match the Probe or Backend Setting hostname of the application gateway".

I checked the PDF you shared, and I could see the backend health is returning a 400 HTTP status code.

HTTP 400 response codes are commonly observed when:

• Non-HTTP / HTTPS traffic is initiated to an application gateway with an HTTP or HTTPS listener.
• HTTP traffic is initiated to a listener with HTTPS, with no redirection configured.
• Mutual authentication is configured and unable to properly negotiate.
• The request isn't compliant to RFC.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/http-response-codes#400--bad-request

So, requested you to check the reasons listed in the above document to validate that you are not hitting any of them.

If all the above checks out, then try to setup the custom health probe as below and try again:

And set "override hostname" in the Backend Setting to NO.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-probe-overview#some-use-cases-for-custom-probes

You confirmed that the above custom health probe setting works but have doubts regarding the limits as you have 150 HTTPS sites,

Looking at your issue, I would like to share the below points:

As mentioned in the below troubleshooting document; to fix the Common Name (CN) mismatch issue, you should do the following:

• If you’re using a Default Probe – You can specify a hostname in the associated Backend setting of your application gateway. You can select “Override with specific hostname” or “Pick hostname from backend target” in the backend setting.
• If you’re using a Custom Probe – For Custom Probe, you can use the “host” field to specify the Common Name of the backend server certificate. Alternatively, if the Backend Setting is already configured with the same hostname, you can choose “Pick hostname from backend setting” in the probe settings.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-backend-health-troubleshooting#common-name-cn-doesnt-match

1. You tried the first solution, but it failed:

https://site01.domain.com -> appgw listener-https (*.domain.com) -> backend setting (Override with new host name:yes, Override with specific domain name hostname *.domain.com) -> backend health is failing

This could be failing because the default probe is marking the backend as unhealthy due to the probe failure.

The default probe looks only at <protocol>://127.0.0.1:<port> to determine health status.

So, if you're using host-headers and SNI on HTTPS bindings and you do not receive a response and certificate from a manual browser request to https://127.0.0.1/ on the backend servers, you must set up a default TLS binding on them. If you do not do so, probes fail, and the back end is not allowed.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-end-to-end-ssl-powershell#create-an-application-gateway-configuration-object

2. The second solution is the one I shared above.

When a backend server has a wildcard certificate (*.contoso.com) installed to serve different sub-domains, you can use a Custom probe with a specific hostname (required for SNI) that is accepted to establish a successful TLS probe and report that server as healthy. With "override hostname" in the Backend Setting set to NO, the different incoming hostnames (subdomains) will be passed as is to the backend.

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-probe-overview#some-use-cases-for-custom-probes

The following works, but for each site, we need specific settings and probes, and we have over 150 HTTPS sites, with a limit of 100 backend settings and health probes in APPGW. <---- You don't have to add custom health probe for each sub-domain. You can create a single custom health probe with site01.domain.com and associate it to the single wildcard listener and backend setting and this should work.

This is mentioned in the below document:

For backend health check, you can't associate multiple custom probes per HTTP settings. Instead, you can probe one of the websites at the backend or use "127.0.0.1" to probe the localhost of the backend server. However, when you're using wildcard or multiple host names in a listener, the requests for all the specified domain patterns are routed to the backend pool depending on the rule type (basic or path-based).

Refer: https://learn.microsoft.com/en-us/azure/application-gateway/multiple-site-overview#considerations-and-limitations-of-using-wildcard-or-multiple-host-names-in-a-listener

Kindly let us know if the above helps or you need further assistance on this issue.

---

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