Infrastructure
Azure Application Gateway: validate a Key Vault certificate before rotation
A production runbook for qualifying an Application Gateway TLS certificate rotation from Key Vault with managed identity, listener checks, WAF evidence, probes, logs, validation and rollback.
Rotating a TLS certificate on Application Gateway often looks like a small operation: upload a new Key Vault version, wait for synchronization, check the listener, then close the change. In production, that is rarely enough. A wrong secret, a managed identity without access, an incomplete chain, a listener still serving the old version or a probe failing after cutover can turn a preventive rotation into an edge incident.
The use case is an application exposed through Azure Application Gateway, sometimes with WAF, where the certificate is stored in Azure Key Vault. The team must replace or renew the certificate before expiry without breaking the HTTPS path, widening vault access or mixing TLS, backend health, WAF and DNS symptoms. The runbook goal is to decide whether rotation can proceed, whether it must wait, or whether rollback should restore the previous certificate version.
Name the TLS path to protect
Start with one hostname and one listener. Certificate rotation is not validated at the generic gateway level. It is validated on the path actually consumed by users, probes and dependencies.
Rotation to qualify
Application Gateway: agw-prod-edge
Hostname: app.example.com
Listener: https-app-prod
Key Vault: kv-prod-platform
Certificate: app-example-com
Access identity: gateway user-assigned managed identity
Window: preventive rotation before expiry
Paths to validate: browser, synthetic probe, backend health, WAF logs
Evidence required before cutover
Current certificate version and expiry date
New version present in Key Vault
Intermediate chain and SAN verified
Secret read permission for the gateway identity
Listener mapped to the expected certificate
External probe with real SNI and hostname
Rollback to previous version documentedIf the change record does not name the hostname, listener and target certificate version, the rotation is not yet controllable.
Separate expiry, content and vault access
Three failures can look similar: the certificate expires, the new certificate is wrong, or Application Gateway cannot read it. Diagnostics should therefore separate dates, certificate content and Key Vault access.
RESOURCE_GROUP="rg-prod-network"
KEY_VAULT="kv-prod-platform"
CERT_NAME="app-example-com"
az keyvault certificate show --vault-name "$KEY_VAULT" --name "$CERT_NAME" --query "{name:name,enabled:attributes.enabled,notBefore:attributes.notBefore,expires:attributes.expires,secretId:sid}" --output table
az keyvault certificate list-versions --vault-name "$KEY_VAULT" --name "$CERT_NAME" --query "[].{version:id,enabled:attributes.enabled,expires:attributes.expires,created:attributes.created}" --output tableKeep the version identifier in the change note. A certificate name alone is not enough to explain what was served before, during and after rotation.
Verify the gateway managed identity
Application Gateway must be able to read the secret behind the certificate. Rotation can fail even when the certificate is valid if the managed identity lost access, the vault authorization model changed, or a policy modified permissions.
APP_GW_ID="/subscriptions/<subscription-id>/resourceGroups/rg-prod-network/providers/Microsoft.Network/applicationGateways/agw-prod-edge"
IDENTITY_PRINCIPAL_ID="11111111-1111-1111-1111-111111111111"
KEY_VAULT_SCOPE="/subscriptions/<subscription-id>/resourceGroups/rg-prod-platform/providers/Microsoft.KeyVault/vaults/kv-prod-platform"
az network application-gateway show --ids "$APP_GW_ID" --query "{identity:identity,sslCertificates:sslCertificates[].{name:name,keyVaultSecretId:keyVaultSecretId}}" --output json
az role assignment list --assignee "$IDENTITY_PRINCIPAL_ID" --scope "$KEY_VAULT_SCOPE" --query "[].{role:roleDefinitionName,scope:scope}" --output tableThe fix should not be to add a broad subscription-level role just to unblock rotation. The right scope is read access to the required secret, with proof that the gateway is using that identity.
Read the listener before touching WAF
An HTTPS failure can trigger WAF alerts, broken probes or client-side 502s. Do not edit WAF rules until the TLS listener is understood.
RESOURCE_GROUP="rg-prod-network"
APP_GW="agw-prod-edge"
az network application-gateway http-listener list --resource-group "$RESOURCE_GROUP" --gateway-name "$APP_GW" --query "[].{name:name,hostNames:hostNames,protocol:protocol,sslCertificate:sslCertificate.id,frontendIP:frontendIPConfiguration.id}" --output table
az network application-gateway ssl-cert list --resource-group "$RESOURCE_GROUP" --gateway-name "$APP_GW" --query "[].{name:name,keyVaultSecretId:keyVaultSecretId,provisioningState:provisioningState}" --output tableIf several listeners share the same certificate, list them explicitly. A rotation can be valid for the primary hostname and still break a forgotten alias.
Test the certificate like a client
Validation must leave the portal. Test the hostname, SNI, chain and dates actually served by Application Gateway from a representative network.
HOSTNAME="app.example.com"
openssl s_client -connect "${HOSTNAME}:443" -servername "$HOSTNAME" -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
curl -vkI "https://${HOSTNAME}/health" --resolve "${HOSTNAME}:443:<application-gateway-public-or-private-ip>" --max-time 10The test must use the real hostname. Validating only the IP address, without SNI, can miss the production listener.
Correlate gateway, WAF and probe logs
During the rotation window, keep a short view over logs. Look for handshake symptoms, backend health changes, 502 responses and WAF blocks that appear after cutover.
let rotationStart = datetime(2026-07-08T18:00:00Z);
let rotationEnd = datetime(2026-07-08T19:00:00Z);
AzureDiagnostics
| where TimeGenerated between (rotationStart .. rotationEnd)
| where ResourceProvider == "MICROSOFT.NETWORK"
| where Category in ("ApplicationGatewayAccessLog", "ApplicationGatewayFirewallLog", "ApplicationGatewayPerformanceLog")
| extend host = coalesce(host_s, originalHost_s, requestUri_s)
| where host has "app.example.com"
| summarize
requests=count(),
errors=countif(httpStatus_d >= 500),
wafBlocks=countif(action_s =~ "Blocked"),
sampleStatus=make_set(tostring(httpStatus_d), 10)
by bin(TimeGenerated, 5m), Category
| order by TimeGenerated ascA burst of WAF blocks after rotation can be correlated, but it is not necessarily caused by the certificate. Keep TLS evidence separate from application evidence.
Decide rotation, hold or rollback
The decision should be readable by operations. Rotation can proceed when Key Vault access, the listener, the TLS chain and probes are validated. It should wait when any one of those proofs is missing.
Allow rotation
The new version is enabled in Key Vault
The certificate chain is complete and covers the hostname
The gateway managed identity can read the secret at the right scope
The listener points to the expected certificate
The TLS probe with SNI passes from a representative network
Gateway and WAF logs stay inside the expected envelope
Hold before rotation
The target version is not identified
The certificate does not contain the required SAN
The gateway identity does not have bounded secret access
Multiple consuming listeners are not inventoried
Probes or logs cannot validate the cutover
Rollback
The gateway does not serve the new certificate
Clients see a chain or name error
HTTPS probes fail after cutover
502 responses increase without another application change
The previous version is still available and validatedRollback should be as precise as rotation: restore the previous secret version or the previous certificate configured on the gateway, then repeat TLS and application probes. Do not roll back WAF or DNS to fix a certificate issue without evidence.
Keep reusable evidence
After the window, store the result as operational evidence. It prevents the team from rediscovering the path at every renewal.
## TLS certificate rotation evidence
- Hostname: app.example.com
- Application Gateway listener: https-app-prod
- Key Vault certificate: app-example-com
- Previous version: <secret-version-id>
- New version: <secret-version-id>
- Gateway identity: user-assigned managed identity
- Access proof: secret read role scoped to Key Vault
- TLS probe: SNI, SAN, issuer and expiry validated
- Application probe: /health returned expected status
- Logs: no new 5xx or WAF block pattern during watch window
- Decision: rotation promoted, rollback version retained until next windowKeep this trace attached to the change, not only to the renewal ticket. It will be useful for the next TLS incident, the next rotation and security reviews.
Conclusion
An Application Gateway certificate rotation is not just a secret replacement. It is a production operation that crosses Key Vault, managed identity, TLS listeners, WAF, probes and observability.
The safe decision comes from short evidence: known target version, bounded vault access, valid TLS chain, verified listener, real probes and ready rollback. When those elements are visible, rotation becomes repeatable. When they are missing, the team should hold instead of discovering the problem at the first client handshake.