Azure App Gateway Missing HTTPS Listener Fix | Lensix

TL;DR

This check flags Azure Application Gateways that serve traffic without any HTTPS listener, meaning client connections fall back to plaintext HTTP. Add an HTTPS listener bound to a TLS certificate (ideally from Key Vault) and redirect HTTP to HTTPS to encrypt traffic in transit.

An Application Gateway sits at the front door of your web workloads in Azure. It terminates client connections, routes requests to backend pools, and often acts as your web application firewall. If that front door only speaks HTTP, every request and response between your users and the gateway travels across the network in cleartext. The appgateway_nohttps check exists to catch exactly that: a gateway with zero HTTPS listeners configured.

What this check detects

Lensix inspects each Azure Application Gateway in your subscriptions and looks at its listener configuration. A listener defines how the gateway accepts incoming connections: the protocol (HTTP or HTTPS), the port, the hostname, and, for HTTPS, the TLS certificate to present.

The check fails when a gateway has listeners but none of them use the HTTPS protocol. In practice this means the gateway is only accepting plaintext traffic on ports like 80, and there is no path for clients to establish an encrypted session.

Note: Application Gateway terminates TLS at the gateway by default. The listener protocol controls the connection between the client and the gateway. A separate setting, the backend HTTP setting, controls whether traffic from the gateway to your backend pool is re-encrypted. Both legs matter, but this check focuses on the client-facing leg.

Why it matters

Plaintext HTTP between users and your gateway is a real, exploitable problem, not a theoretical one.

Credentials and session tokens in the clear. Login forms, API keys, bearer tokens, and session cookies all travel unencrypted. Anyone positioned on the network path, a compromised Wi-Fi access point, a malicious ISP hop, or an attacker who has gained a foothold in the same virtual network, can read them.
Man-in-the-middle injection. Without TLS there is no integrity guarantee. An attacker can modify responses in transit, inject malicious JavaScript, or redirect users to a phishing page.
No server authentication. Clients cannot verify they are actually talking to your gateway. This makes spoofing and impersonation attacks straightforward.
Compliance failures. PCI DSS, HIPAA, SOC 2, and most modern frameworks require encryption of data in transit. An HTTP-only gateway will fail those audits.

A common way this slips into production: an engineer spins up a gateway for quick testing with an HTTP listener, the workload graduates to production, and nobody ever revisits the listener config. The gateway keeps serving real user traffic in cleartext for months.

Warning: Browsers increasingly mark HTTP pages as "Not Secure" and block features like geolocation, service workers, and clipboard access on insecure origins. Beyond the security risk, an HTTP-only gateway can break application functionality your users expect.

How to fix it

Fixing this means adding an HTTPS listener backed by a TLS certificate, then redirecting HTTP traffic to it. You will need a certificate. The cleanest approach is storing it in Azure Key Vault and referencing it from the gateway, but you can also upload a PFX directly.

Step 1: Get a certificate into the gateway

If you already have a certificate in Key Vault, grab its secret identifier. The gateway uses a managed identity to read it.

# Create a user-assigned managed identity for the gateway (if you don't have one)
az identity create \
  --resource-group myResourceGroup \
  --name appgw-identity

# Grant it permission to read secrets from Key Vault
az keyvault set-policy \
  --name myKeyVault \
  --object-id $(az identity show -g myResourceGroup -n appgw-identity --query principalId -o tsv) \
  --secret-permissions get \
  --certificate-permissions get

Step 2: Add the SSL certificate reference and HTTPS listener

# Attach the managed identity to the Application Gateway
az network application-gateway identity assign \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --identity appgw-identity

# Reference the Key Vault certificate
az network application-gateway ssl-cert create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name mySslCert \
  --key-vault-secret-id "https://myKeyVault.vault.azure.net/secrets/mycert"

# Create the HTTPS listener on port 443
az network application-gateway http-listener create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name httpsListener \
  --frontend-port appGwFrontendHttpsPort \
  --ssl-cert mySslCert

Note: If you do not already have a frontend port for 443, create one with az network application-gateway frontend-port create --port 443 and reference its name in the listener command above.

Step 3: Add a routing rule for the HTTPS listener

az network application-gateway rule create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name httpsRule \
  --http-listener httpsListener \
  --rule-type Basic \
  --address-pool myBackendPool \
  --http-settings myHttpSettings \
  --priority 100

Step 4: Redirect HTTP to HTTPS

Adding HTTPS is not enough on its own. Keep an HTTP listener around, but configure it to redirect to HTTPS so users who type http:// end up on a secure connection.

az network application-gateway redirect-config create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name httpToHttps \
  --type Permanent \
  --target-listener httpsListener \
  --include-path true \
  --include-query-string true

az network application-gateway rule create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name httpRedirectRule \
  --http-listener httpListener \
  --rule-type Basic \
  --redirect-config httpToHttps \
  --priority 200

Warning: Modifying listeners and rules on a live gateway triggers a reconfiguration that can briefly interrupt traffic. Apply changes during a maintenance window, and watch for rule priority conflicts since every request routing rule needs a unique priority value.

Terraform example

If you manage infrastructure as code, here is the relevant section of an azurerm_application_gateway resource with an HTTPS listener and an HTTP-to-HTTPS redirect.

frontend_port {
  name = "https-port"
  port = 443
}

ssl_certificate {
  name                = "mySslCert"
  key_vault_secret_id = "https://myKeyVault.vault.azure.net/secrets/mycert"
}

http_listener {
  name                           = "httpsListener"
  frontend_ip_configuration_name = "appGwPublicFrontendIp"
  frontend_port_name             = "https-port"
  protocol                       = "Https"
  ssl_certificate_name           = "mySslCert"
}

request_routing_rule {
  name                       = "httpsRule"
  rule_type                  = "Basic"
  http_listener_name         = "httpsListener"
  backend_address_pool_name  = "myBackendPool"
  backend_http_settings_name = "myHttpSettings"
  priority                   = 100
}

redirect_configuration {
  name                 = "httpToHttps"
  redirect_type        = "Permanent"
  target_listener_name = "httpsListener"
  include_path         = true
  include_query_string = true
}

request_routing_rule {
  name                        = "httpRedirectRule"
  rule_type                   = "Basic"
  http_listener_name          = "httpListener"
  redirect_configuration_name = "httpToHttps"
  priority                    = 200
}

Tip: Reference certificates from Key Vault instead of uploading raw PFX files into your IaC. Key Vault handles rotation, and the gateway picks up renewed certificates automatically when you use the secret identifier without a version pinned. That removes the recurring chore of redeploying every time a cert expires.

How to prevent it from happening again

Catching this once is good. Making it impossible to ship an HTTP-only gateway is better.

Azure Policy

Use Azure Policy to audit or deny gateways that lack an HTTPS listener. You can assign a policy that flags non-compliant gateways at the subscription or management group level so the whole organization inherits the guardrail.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Network/applicationGateways"
      },
      {
        "count": {
          "field": "Microsoft.Network/applicationGateways/httpListeners[*]",
          "where": {
            "field": "Microsoft.Network/applicationGateways/httpListeners[*].protocol",
            "equals": "Https"
          }
        },
        "equals": 0
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

CI/CD gates

If your gateways live in Terraform or Bicep, scan the plan before it applies. Tools like Checkov, tfsec, and Trivy understand Application Gateway resources and can fail a pipeline when no HTTPS listener is defined.

# Run Checkov against your Terraform plan in CI
checkov -d ./infra --framework terraform

Tip: Pair a policy-as-code scan in the pull request with continuous monitoring from Lensix on the deployed environment. The scan catches issues before merge, and Lensix catches drift and out-of-band changes made directly in the portal.

Best practices

Enforce a minimum TLS version. Set the gateway's SSL policy to require TLS 1.2 or higher and disable weak ciphers. Use a predefined policy like AppGwSslPolicy20220101 or a custom one.
Re-encrypt to the backend where it matters. Terminating TLS at the gateway is fine, but for sensitive workloads configure end-to-end TLS so the hop from gateway to backend is encrypted too.
Automate certificate rotation. Store certificates in Key Vault and let the gateway sync renewals. Expired certificates are one of the most common causes of avoidable outages.
Always redirect HTTP to HTTPS. Do not just turn off port 80. Keep it open with a redirect so existing links and bookmarks keep working over a secure connection.
Turn on the WAF. If you are paying for Application Gateway, the WAF v2 SKU gives you managed OWASP rule sets that protect against common injection and exploitation attempts. Encryption and a firewall together cover both confidentiality and threat protection.
Log and monitor. Send Application Gateway access and firewall logs to Log Analytics so you can see protocol usage and spot any traffic still landing on HTTP listeners.

Danger: Do not delete an existing HTTP listener until the HTTPS listener and redirect are live and verified. Removing the only listener that has active routing rules can take your application offline immediately, and the change is not instant to roll back.

An Application Gateway without HTTPS is one of those misconfigurations that looks harmless in a dev environment and becomes a liability the moment real users show up. The fix is straightforward, the prevention is automatable, and the payoff is encrypted, authenticated traffic at the edge of your application. Get the listener in place, redirect HTTP to it, and let policy keep it that way.

Application Gateway Has No HTTPS Listener: Why It Matters and How to Fix It