Check the certificate Application Gateway v2 returns without SNI

Source facts

When a client connects to Application Gateway v2 without an SNI header, such as by address rather than hostname, the gateway returns the certificate associated with the highest-priority HTTPS routing rule. The highest priority is the lowest numeric priority value.

Microsoft explicitly says that v2 does not use a basic listener’s certificate as a fallback for this situation. The expected certificate therefore needs to be checked against routing-rule priority, not just listener type. Microsoft Learn.

Applicability

Inventory the HTTPS listeners, their certificates, and associated rule priorities. Identify any client or monitoring path that may omit the server name, and keep that case separate from ordinary hostname-based TLS testing.

DSE recommendation

DSE recommends recording the approved no-SNI certificate behavior in the gateway’s listener review. Have the certificate and application owners assess whether the selected certificate is appropriate for that connection. Revisit the decision whenever listener or rule priorities change; do not assume a newly added listener leaves the fallback behavior unchanged.

Verification

From an approved test client, inspect the certificate once with the intended server name and once without SNI. Compare both results with the listener inventory and priority order. Repeat after a representative configuration change, preserving certificate identifiers and handshake evidence. Keep the application response check separate from the certificate-selection result.

Official references

Microsoft Learn: Enabling end to end TLS on Azure Application Gateway. Source retrieved September 9, 2026.