8.1 Azure Application Gateway Security, TLS Policy & Mutual Authentication

Where Application Gateway Fits

Application Gateway is a regional, layer 7 reverse proxy. It terminates HTTP and HTTPS, makes routing decisions on host name and URL path, and is the hosting point for the regional Web Application Firewall (WAF_v2). Compare it with the other front-end services:

A common enterprise pattern chains them: Front Door at the edge for global routing and DDoS/WAF, then Application Gateway regionally for VNet-internal routing and mutual TLS.

---

Deployment Prerequisites That Break Things

• Dedicated subnet. The gateway must live in its own subnet containing no other resource type. Microsoft recommends a /24; the platform reserves addresses for each instance and for scale-out.
• Inbound TCP 65200–65535 from the GatewayManager service tag must be allowed on the subnet NSG for v2 SKUs. This is control-plane traffic protected by certificates; blocking it does not "harden" the gateway, it makes the gateway report unhealthy and stop receiving configuration. This is one of the most reliably tested facts on the objective.
• Outbound internet access is required for CRL/OCSP checks and platform communication. If you force-tunnel 0.0.0.0/0 off the gateway subnet, the gateway breaks unless the required destinations remain reachable.
• Network isolation (private-only deployment) allows a v2 gateway with a private frontend IP only, no public IP, which is what you deploy behind Front Door or for internal line-of-business apps.

---

Certificates and TLS Policy

Key Vault integration

Rather than uploading a PFX to the gateway, reference the certificate in Azure Key Vault:

1. Create a user-assigned managed identity and attach it to the gateway.
2. Grant that identity Key Vault Secrets User (RBAC model) or a get-secret access policy.
3. Point the HTTPS listener at the Key Vault certificate's secret identifier.

Benefits: rotation happens in Key Vault and the gateway picks up the new version, the private key never sits in a deployment pipeline, and access is auditable. If the gateway's Key Vault firewall blocks it, add the gateway subnet or use a private endpoint plus the trusted-services allowance.

TLS policy

A TLS (SSL) policy controls the minimum protocol version and the cipher suite list.

• Predefined policies (for example the 2022 policy set) are curated by Microsoft and update over time.
• A custom policy lets you pin the minimum version to TLS 1.2 or 1.3 and enumerate exactly which cipher suites are offered — the answer whenever a scenario says "the audit found CBC ciphers / TLS 1.0 must be impossible".
• Policies can be applied gateway-wide or per listener through an SSL profile.

End-to-end TLS

By default the gateway decrypts at the listener and may talk plain HTTP to the backend. End-to-end TLS re-encrypts on the backend side. For a v2 gateway, the backend's certificate must be trusted: upload the backend's root certificate as a trusted root certificate on the backend HTTP setting, or use a certificate issued by a well-known CA. Self-signed backend certificates without this step produce a 502 with an "unhealthy backend" probe result.

---

Mutual TLS (Client Certificate Authentication)

Mutual TLS makes the client prove its identity with a certificate before the request is proxied. Configuration:

1. Build an SSL profile.
2. Upload the trusted client CA certificate chain — the full chain, not just the leaf.
3. Associate the SSL profile with the listener that must require client certificates.
4. Optionally enable certificate chain verification and use header rewrite to pass client certificate attributes (subject, issuer, thumbprint, validity) to the backend so the app can authorize on them.

Mutual TLS is the standard answer for partner-to-partner APIs, IoT device fleets, and B2B integrations where the caller cannot use an interactive identity. Remember that it authenticates the transport, not a user — the backend still needs authorization logic.

---

Layered Controls Around the Gateway

• WAF_v2 policy attached to the gateway, a listener, or a path-based rule — Prevention mode with a managed core rule set, plus custom rules for rate limiting and geo-filtering.
• NSG on the backend subnet allowing traffic only from the gateway subnet, so nobody can bypass the gateway by hitting the VM directly.
• Private endpoints on backend PaaS resources, so the gateway is the only reachable path.
• Health probes with custom match conditions, so a compromised or broken backend is removed from rotation instead of serving errors.
• Diagnostic logs (ApplicationGatewayAccessLog, ApplicationGatewayFirewallLog, ApplicationGatewayPerformanceLog) shipped to a Log Analytics workspace, which is what feeds Microsoft Sentinel detections for web attacks.