CN of backend server certificate does not match the host header in health probe configuration

Avinash Davkhar 20 Reputation points
2024-09-03T12:39:19.7+00:00

"The Common Name (CN) of the backend server certificate is inconsistent with the host header specified in the health probe configuration (v2 SKU) or the Fully Qualified Domain Name (FQDN) in the backend pool (v1 SKU). Please confirm that the hostname aligns with the CN of the backend server certificate"

I encountered this error while attempting to add a health probe.

The CN of the certificate is formatted as *.develop.xyz.com.

However, the health probe does not accept *.develop.xyz.com as the host; it only accepts develop.xyz.com.

I would appreciate your guidance on resolving this issue.

User's image

Azure Application Gateway
Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,048 questions
0 comments No comments
{count} votes

Accepted answer
  1. ChaitanyaNaykodi-MSFT 25,841 Reputation points Microsoft Employee
    2024-09-03T23:09:38.4866667+00:00

    @Avinash Davkhar

    Thank you for reaching out.

    I understand you are trying to set up a custom health probe for your App Gateway with wild card domains where CN of the certificate is formatted as *.develop.xyz.com. When you enter *.develop.xyz.com as the host name. You get the error "The Common Name (CN) of the backend server certificate is inconsistent with the host header specified in the health probe configuration (v2 SKU) or the Fully Qualified Domain Name (FQDN) in the backend pool (v1 SKU). Please confirm that the hostname aligns with the CN of the backend server certificate"

    The observation above is expected as you need to enter a specific host name for the custom health probe as it is used both as host header and SNI.

    A specific hostname in this case will be for example "abc.develop.xyz.com" that is accepted to establish a successful TLS probe and report that server as healthy. This host name is where the custom health probe will be sent to determine the health of the backend. This currently documented here.

    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.

    I understand this way only one website will be probed to determine the health, this is currently documented here in the Considerations and limitations of using wildcard

    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.

    Additional references:

    https://video2.skills-academy.com/en-us/azure/application-gateway/application-gateway-faq#do-custom-probes-support-wildcards-or-regex-on-response-data

    https://video2.skills-academy.com/en-us/azure/application-gateway/application-gateway-faq#for-custom-probes--what-does-the---host---field-signify

    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.


0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.