Azure Application Gateway : valider un certificat Key Vault avant rotation

Une rotation de certificat TLS sur Application Gateway ressemble souvent à une opération simple : déposer une nouvelle version dans Key Vault, attendre la synchronisation, vérifier le listener, puis fermer le ticket. En production, c’est rarement suffisant. Un mauvais secret, une identité managée sans droit, une chaîne incomplète, un listener qui garde l’ancienne version ou une probe qui échoue après bascule peuvent transformer une rotation préventive en incident frontal.

Le cas d’usage est une application exposée par Azure Application Gateway, parfois avec WAF, dont le certificat est stocké dans Azure Key Vault. L’équipe doit remplacer ou renouveler le certificat avant expiration sans casser le chemin HTTPS, sans ouvrir le coffre trop largement et sans confondre problème TLS, backend health, WAF ou DNS. Le but du runbook est de décider si la rotation peut partir, si elle doit attendre, ou si le rollback doit rétablir la version précédente du certificat.

Nommer le chemin TLS à protéger

Commencez par isoler un hostname et un listener. Une rotation de certificat ne se valide pas au niveau “gateway” en général : elle se valide sur le chemin réellement consommé par les utilisateurs, les probes et les dépendances.

Rotation a qualifier
Application Gateway: agw-prod-edge
Hostname: app.example.com
Listener: https-app-prod
Key Vault: kv-prod-platform
Certificat: app-example-com
Identite d'acces: user-assigned managed identity de la gateway
Fenetre: rotation preventive avant expiration
Chemins a valider: navigateur, probe synthetique, backend health, WAF logs

Preuves requises avant bascule
Version actuelle du certificat et date d'expiration
Nouvelle version presente dans Key Vault
Chaine intermediaire et SAN verifies
Droit de lecture secret pour l'identite de la gateway
Listener associe au bon certificat
Probe externe avec SNI et hostname reels
Rollback vers l'ancienne version documente

Si le ticket ne contient pas le hostname, le listener et la version de certificat visée, la rotation n’est pas encore une opération contrôlable.

Séparer expiration, contenu et accès au coffre

Trois pannes se ressemblent : le certificat expire, le nouveau certificat est incorrect, ou Application Gateway ne peut pas le lire. Les diagnostics doivent donc séparer les dates, le contenu et l’accès Key Vault.

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 table

Gardez l’identifiant de version dans la note de changement. Un nom de certificat seul ne suffit pas pour expliquer ce qui a été présenté avant, pendant et après la rotation.

Vérifier l’identité managée de la gateway

Application Gateway doit pouvoir lire le secret associé au certificat. Une rotation peut échouer alors que le certificat est valide si l’identité managée n’a plus le droit, si le coffre a changé de modèle d’autorisation ou si une policy a modifié l’accès.

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 table

La correction ne doit pas être d’ajouter un rôle large au niveau subscription pour “débloquer” la rotation. Le bon périmètre est la lecture du secret nécessaire, avec une preuve que la gateway utilise bien cette identité.

Lire le listener avant de toucher au WAF

Un échec HTTPS peut déclencher des alertes WAF, des probes en erreur ou des 502 côté client. Ne modifiez pas les règles WAF tant que le listener TLS n’est pas compris.

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 table

Si plusieurs listeners partagent le même certificat, listez-les explicitement. Une rotation peut être valide pour le hostname principal et casser un alias oublié.

Tester le certificat comme un client

La validation doit sortir du portail. Testez le hostname, le SNI, la chaîne et la date réellement servis par Application Gateway depuis un réseau représentatif.

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 10

Le test doit utiliser le vrai hostname. Une validation sur adresse IP, sans SNI, peut passer à côté du listener réellement utilisé en production.

Corréler logs gateway, WAF et probes

Pendant la fenêtre de rotation, gardez une vue courte sur les logs. Cherchez les erreurs de handshake, les changements de backend health, les réponses 502 et les blocages WAF qui apparaissent après la bascule.

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 asc

Un pic de WAF blocks après rotation peut être corrélé, mais il n’est pas forcément causé par le certificat. Gardez la preuve TLS séparée de la preuve applicative.

Décider rotation, attente ou rollback

La décision doit être lisible par l’exploitation. La rotation peut partir quand l’accès Key Vault, le listener, la chaîne TLS et les probes sont validés. Elle doit attendre si une seule de ces preuves manque.

Autoriser la rotation
La nouvelle version est active dans Key Vault
La chaine certificat est complete et couvre le hostname
L'identite managée de la gateway lit le secret au bon scope
Le listener pointe vers le certificat attendu
La probe TLS avec SNI passe depuis un réseau représentatif
Les logs gateway et WAF restent dans l'enveloppe attendue

Attendre avant rotation
La version cible n'est pas identifiee
Le certificat ne contient pas le SAN requis
L'identite gateway n'a pas un acces borne au secret
Plusieurs listeners consommateurs ne sont pas inventoriés
Les probes ou logs ne permettent pas de valider la bascule

Rollbacker
La gateway ne présente pas le nouveau certificat
Les clients voient une erreur de chaine ou de nom
Les probes HTTPS échouent après bascule
Les 502 augmentent sans autre changement applicatif
L'ancienne version est encore disponible et validée

Le rollback doit être aussi précis que la rotation : revenir à l’ancienne version du secret ou au précédent certificat configuré sur la gateway, puis refaire les probes TLS et applicatives. Ne rollbackez pas un changement WAF ou DNS pour corriger un certificat sans preuve.

Garder une trace réutilisable

Après la fenêtre, conservez le résultat sous forme de preuve d’exploitation. Cela évite de redécouvrir le même chemin à chaque renouvellement.

## 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 window

Cette trace doit rester attachée au changement, pas seulement au ticket de renouvellement. Elle servira au prochain incident TLS, à la prochaine rotation et aux revues de sécurité.

Conclusion

Une rotation de certificat Application Gateway n’est pas un simple remplacement de secret. C’est une opération de production qui traverse Key Vault, identité managée, listener TLS, WAF, probes et observabilité.

La bonne décision repose sur des preuves courtes : version cible connue, accès au coffre borné, chaîne TLS valide, listener vérifié, probes réelles et rollback prêt. Quand ces éléments sont visibles, la rotation devient répétable. Quand ils manquent, l’équipe doit attendre plutôt que découvrir le problème au premier handshake client.