Azure Application Gateway SSL expired

azure application gateway ssl expired on the HTTPS listener stops every client hitting your public IP or Application Gateway front-end DNS—no amount of App Service certificate renewal fixes that listener binding alone.

Application Gateway v2 terminates TLS on listeners tied to SSL certificates stored on the gateway or referenced from Azure Key Vault. Multi-site listeners route host names to different backend pools; each listener or listener rule can reference a certificate object by name.

Operations teams renew App Service managed certs or VM PEM files while the gateway still serves last year’s PFX uploaded manually during the original cutover. Incidents surface as uniform TLS failures across backend pools that share the same listener certificate.

You will inventory sslCerts, map listeners and rules, upload or sync Key Vault material, and openssl the customer hostname on the public listener IP or custom domain CNAME.

Security teams sometimes rotate Key Vault access policies during zero-trust projects. Schedule those changes outside certificate renewal windows so gateway managed identity never loses Get permission the day before commercial notAfter.

What to check

List sslCerts on the Application Gateway resource and match names to httpListeners that expose port 443. Key Vault–integrated certs need the gateway managed identity with Get permission on secrets and certificates.

Confirm customer DNS: CNAME to the gateway public DNS label or A record to the static front-end IP. Openssl always uses the hostname users type, with SNI matching listener host names.

Distinguish Application Gateway from Azure Front Door—both terminate TLS but use different portals and certificate objects. This guide targets Application Gateway; Front Door uses its own secret and managed certificate models.

Cross-reference load balancer presenting an expired certificate when App Gateway sits behind another regional load balancer or CDN.

Record whether certificates are Key Vault integrated or uploaded PFX in your CMDB. Managed identity permission drift on Key Vault is a top cause of renewal scripts succeeding in the vault while the gateway never ingests the new secret version. Multi-pool gateways may expose several HTTPS listeners; openssl every listener hostname, not only the primary portal.

Step-by-step

External TLS capture

HOST=portal.contoso.com
echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -serial -subject

Inventory with Azure CLI

az network application-gateway show -g RG_NAME -n APPGW_NAME \
  --query '{listeners:httpListeners[].{name:name,host:hostName,proto:protocol,port:frontendPort.id},
            certs:sslCertificates[].{name:name,proto:protocol}}' -o yaml

List SSL cert objects and listener host names:

az network application-gateway ssl-cert list -g RG_NAME --gateway-name APPGW_NAME -o table
az network application-gateway http-listener list -g RG_NAME --gateway-name APPGW_NAME -o table

Upload renewed PFX (manual cert path)

az network application-gateway ssl-cert update -g RG_NAME --gateway-name APPGW_NAME \
  --name listener-cert-contoso \
  --cert-file ./renewed-contoso.pfx \
  --cert-password 'PFX_PASSWORD'

Or create a new ssl-cert and point the listener:

az network application-gateway ssl-cert create -g RG_NAME --gateway-name APPGW_NAME \
  --name contoso-2026 --cert-file ./renewed.pfx --cert-password 'PFX_PASSWORD'
az network application-gateway http-listener update -g RG_NAME --gateway-name APPGW_NAME \
  --name https-listener-contoso --ssl-cert contoso-2026

Gateway applies updates without rebooting backend pools; allow a few minutes for control plane propagation.

Paste az network application-gateway show output snippets into the ticket when multiple listeners exist so the next shift knows which sslCert name was actually swapped.

Key Vault reference path

Ensure secret or certificate version in Key Vault includes the renewed full chain. Application Gateway polls Key Vault versions configured on the sslCert resource—bump the version after renewal:

az keyvault certificate show --vault-name KV_NAME -n contoso-wildcard \
  --query 'sid' -o tsv

Update the gateway sslCert to reference the new version via portal TLS/SSL settings or ARM/Bicep template deployment your team uses.

Portal equivalent

Application gateway → Listeners → select HTTPS listener → Edit → choose updated certificate under Choose a certificate → Save.

Verify

curl -vI --connect-timeout 10 "https://${HOST}/" 2>&1 | grep -Ei 'expire|SSL'

Repeat openssl; serial must change. Hit backend health probes only after TLS is clean—they may have been failing secondary checks during the incident.

Optional: test via public IP when DNS is in flux

IP=20.10.30.40
echo | openssl s_client -connect "${IP}:443" -servername portal.contoso.com 2>/dev/null | openssl x509 -noout -dates

Use this only during controlled cutovers; production validation should always finish on the customer CNAME once DNS stabilizes.

PowerShell external check (Windows operators)

$hostName = "portal.contoso.com"
$tcp = New-Object System.Net.Sockets.TcpClient($hostName, 443)
# Prefer openssl or curl on WSL; above confirms reachability before ticket closure

Document gateway resource ID and sslCert name in the change record so the next renewal bypasses discovery.

How to read the output

az ssl-cert list shows object names, not notAfter—trust openssl on the public hostname after upload. Listener hostName must equal or cover the customer URL; wildcard listener certs need SAN review.

If only one subdomain fails, inspect URL path map or host-name routing rules for listeners using a different sslCert name than the default.

Application Gateway WAF_v2 SKUs share the same certificate model; WAF policy changes do not substitute for cert renewal.

Backend pool members may still answer health probes on HTTP while the listener presents expired TLS to clients—state that clearly in executive updates during azure application gateway ssl expired calls.

When Azure Front Door also fronts the same brand, openssl both hostnames. This guide does not cover Front Door secret rotation; split tickets if only one hop expired.

Common mistakes

Renewing App Service certificates without updating the gateway PFX that still terminates partner traffic.

Uploading leaf-only PFX missing intermediates—some clients fail trust before you notice near-notAfter panic.

Key Vault cert auto-rotation without updating gateway reference version—gateway serves stale secret until version bumps.

Forgetting to include password-protected PFX export from Windows CA with exportable private key.

Testing the azurewebsites.net hostname while customers use a custom domain on the gateway listener.

Removing expired cert objects before attaching the replacement—brief outages during ordered updates.

Confusing Application Gateway classic SKU retirement timelines with certificate objects—v2 SKUs still require explicit PFX or Key Vault updates.

Rotating Azure AD application secrets in the same change window without testing gateway managed identity—Key Vault reads fail and block uploads.

When to use automation

Gateways often front dozens of microservice pools; calendar reminders on PFX purchases do not scale. Monitor live TLS on each public hostname the gateway advertises.

ssldays checks what the internet receives (issuer, SANs, chain, expiry) and alerts at 30, 14, 7, and 1 days. RDAP on the domain supports revalidation when corporate DNS teams lag. Email included on all plans; Slack and Discord on Starter and Pro.

Run /check after every ssl-cert update, then /register for customer hostnames. Compare patterns with AWS ALB listener certificate expired when hybrid cloud estates mirror listener workflows.

Schedule a calendar reminder forty-five days before commercial PFX notAfter even when Key Vault auto-rotation is enabled—gateway ingestion still needs a human or pipeline step to bump secret versions on sslCert objects. That lead time covers CAB approval, partner notifications, and regression testing.