Azure App Service : diagnostiquer un renouvellement TLS avant de rebinder la production

Un certificat App Service a été renouvelé, mais les clients reçoivent toujours l’ancien certificat leaf. Le portail affiche une date d’expiration plus lointaine, le pipeline de déploiement est vert et l’application reste saine. Le réflexe est alors de supprimer le binding TLS, de réimporter le PFX ou de redémarrer toutes les instances. Chacune de ces actions modifie la production avant d’avoir prouvé quel état du certificat est obsolète.

Le cas d’usage est une web app avec un hostname personnalisé et un binding SNI. Son certificat peut être un certificat managé App Service, un App Service Certificate acheté et adossé à Key Vault, ou un certificat importé depuis un coffre géré par l’équipe. Le runbook sépare émission, version du secret, inventaire App Service, binding du hostname et certificat réellement servi. Il aboutit à une décision bornée : attendre, synchroniser, importer, rebinder, corriger la validation ou l’accès, ou restaurer le thumbprint précédent.

Figer le hostname et la chaîne de certificats

Ne partez pas du nom d’affichage du certificat. Notez le hostname exact, l’application, le resource group, le thumbprint observé, le thumbprint attendu, les dates d’expiration et le premier constat UTC. Conservez le binding actuel avant tout changement.

incident:
observed_at_utc: 2026-09-01T07:20:00Z
hostname: api.example.net
app: api-prod
resource_group: rg-app-prod

served_certificate:
sha256_fingerprint: <empreinte-observee>
not_after: <expiration-observee>

expected_certificate:
source: managed-or-app-service-certificate-or-key-vault
thumbprint: <thumbprint-attendu>
secret_version: <version-attendue-ou-non-applicable>
not_after: <expiration-attendue>

preserve:
- binding hostname et type SSL
- etat de la ressource certificat
- versions du secret Key Vault si applicable
- Activity Log autour du renouvellement et du binding
- sorties des probes TLS depuis au moins deux reseaux

stop_conditions:
- le certificat attendu ne couvre pas le hostname
- la cle privee ou la chaine ne peut pas etre validee
- un autre hostname depend du binding modifie
- le thumbprint de rollback n'est plus disponible

Une ressource certificat marquée comme renouvelée ne constitue pas une preuve end-to-end. Le certificat utile est celui renvoyé pour le hostname réel avec SNI ; collectez-le indépendamment de l’état du control plane Azure.

Lire ce que les clients reçoivent réellement

Testez le hostname de production avec SNI. Ne contrôlez pas uniquement l’adresse azurewebsites.net par défaut ou une IP backend : ces tests peuvent sélectionner un autre binding.

HOST="api.example.net"

echo | openssl s_client \
-connect "$HOST:443" \
-servername "$HOST" \
-showcerts 2>/dev/null \
| openssl x509 \
    -noout \
    -subject \
    -issuer \
    -serial \
    -fingerprint \
    -sha256 \
    -dates \
    -ext subjectAltName

curl --silent --show-error --head \
--connect-timeout 5 \
--max-time 15 \
"https://$HOST/health"

Répétez le test depuis une probe externe contrôlée et, pour un hostname interne, depuis le vrai réseau appelant. Des certificats différents selon les probes orientent vers une divergence DNS, un gateway ou un CDN en amont, ou un chemin partiel qui n’atteint jamais App Service. App Service ne peut pas corriger un certificat servi par un autre terminateur TLS.

Séparer les quatre états du certificat

Lisez la chaîne dans l’ordre. D’abord l’émission : le certificat candidat existe-t-il, reste-t-il valide et couvre-t-il le hostname exact dans ses SAN ? Ensuite le stockage : si Key Vault intervient, la version attendue du secret contient-elle le certificat courant et sa clé privée ? Puis l’import : App Service liste-t-il le thumbprint attendu ? Enfin le binding : le hostname personnalisé référence-t-il ce thumbprint avec le type SSL prévu ?

RG="rg-app-prod"
APP="api-prod"
HOST="api.example.net"

az webapp show \
--resource-group "$RG" \
--name "$APP" \
--query "{id:id,state:state,hostNames:hostNames,httpsOnly:httpsOnly}" \
--output json

az webapp config hostname list \
--resource-group "$RG" \
--webapp-name "$APP" \
--query "[?name=='$HOST'].{hostname:name,sslState:sslState,thumbprint:thumbprint}" \
--output json

az webapp config ssl list \
--resource-group "$RG" \
--query "[].{name:name,thumbprint:thumbprint,expiration:expirationDate,hostNames:hostNames,keyVaultId:keyVaultId,keyVaultSecretName:keyVaultSecretName}" \
--output table

Interprétez le premier écart au lieu de déclarer toute la chaîne défaillante :

• l’absence de candidat valide renvoie vers l’émission ou la validation du domaine ;
• une version Key Vault récente sans thumbprint correspondant dans App Service indique un import ou une synchronisation en retard ;
• un certificat App Service présent avec un ancien thumbprint dans le binding indique un binding obsolète ;
• un binding à jour mais un ancien certificat sur le réseau indique un autre terminateur TLS, un hostname de test différent ou une convergence plateforme à qualifier.

Qualifier la source avant de corriger

La correction dépend du propriétaire du renouvellement. Un certificat managé App Service est piloté par la plateforme et ne doit pas être traité comme un PFX téléversé. Un App Service Certificate acheté traverse plusieurs étapes : émission, validation du domaine, stockage Key Vault, import et synchronisation. Un certificat géré dans un Key Vault de l’équipe possède encore un autre cycle de vie pour l’issuer, les versions et l’import App Service.

Pour un App Service Certificate, vérifiez le statut de renouvellement, l’auto-renouvellement, la validation du domaine et les permissions du coffre avant de forcer une synchronisation. La propriété du domaine peut devoir être confirmée de nouveau après la période de validation applicable. Ne lancez pas un rekey pour réparer une simple synchronisation retardée : le rekey change le matériel de clé et constitue un autre événement de sécurité.

Pour un certificat importé depuis Key Vault, comparez les versions du secret et leurs dates d’activation. L’existence d’une nouvelle version dans le coffre ne prouve pas que la ressource certificat App Service l’a importée. Confirmez que la version prévue est activée et contient un PFX exploitable avant de modifier le binding.

Corréler renouvellement, import et binding

Utilisez Azure Activity Log pour reconstruire la séquence du control plane. Les preuves utiles sont l’opération, le resource ID, l’appelant, le résultat et le correlation ID autour de la fenêtre de renouvellement.

let StartTime = datetime(2026-09-01T06:00:00Z);
let EndTime = datetime(2026-09-01T09:00:00Z);
AzureActivity
| where TimeGenerated between (StartTime .. EndTime)
| where ResourceProviderValue in~ ("MICROSOFT.WEB", "MICROSOFT.CERTIFICATEREGISTRATION", "MICROSOFT.KEYVAULT")
| where OperationNameValue has_any (
  "certificates",
  "hostnameBindings",
  "certificateOrders",
  "vaults/secrets"
)
| project TimeGenerated,
        OperationNameValue,
        ActivityStatusValue,
        Caller,
        ResourceId,
        CorrelationId,
        Properties
| order by TimeGenerated asc

Les noms de tables et d’opérations peuvent varier selon le routage des diagnostics. L’objectif est de produire une séquence qui explique si l’émission s’est terminée, si la synchronisation a tourné, si l’import a échoué ou si un déploiement ultérieur a restauré un ancien binding. Un déploiement applicatif vert ne valide pas TLS tant que le pipeline ne contrôle pas explicitement le certificat servi.

Choisir la plus petite correction

Attendre et observer
Renouvellement ou import reste dans la fenetre de convergence documentee
Ancien certificat valide au-dela de la fenetre d'observation
Aucun defaut de hostname ou de chaine

Corriger validation ou acces
Candidat pending, refuse ou absent du stockage
Propriete du domaine ou acces Key Vault est la premiere couche en echec
La correction n'elargit pas les droits de l'identite runtime applicative

Synchroniser ou importer
Nouveau certificat valide et stocke
Inventaire App Service ne contient pas son thumbprint
Binding actuel reste disponible pour rollback

Rebinder
Nouveau thumbprint deja present dans App Service
SAN, chaine et cle privee valides
Binding hostname reference encore l'ancien thumbprint

Rollback
Nouveau binding sert le mauvais nom ou une chaine incomplete
Clients representatifs echouent apres le changement
Certificat precedent encore valide et disponible

Arreter
Un autre gateway termine TLS
Propriete du certificat incertaine
Thumbprint attendu non relie a une emission approuvee

Quand le rebinding est justifié, ne changez que le hostname concerné et conservez l’ancien certificat jusqu’à la fin de la validation. Supprimer l’ancien certificat en premier retire le chemin de retour le plus rapide.

Valider en gardant le rollback ouvert

Après sync, import ou rebinding, rejouez la même probe SNI depuis chaque chemin pertinent. Exigez l’empreinte SHA-256, les SAN, l’issuer et l’expiration attendus. Vérifiez ensuite le statut HTTPS, la santé applicative et les éventuels gateway ou moniteurs synthétiques qui ciblent ce hostname.

Ajoutez au pipeline un gate qui compare le thumbprint attendu au certificat servi sur le réseau. Alertez avant expiration, mais aussi lorsque le thumbprint du binding diverge de l’empreinte servie. Le suivi de l’expiration seul ne détecte pas un certificat renouvelé qui n’a jamais atteint la production.

Conservez le binding et le certificat précédents jusqu’à ce que la nouvelle chaîne survive à une fenêtre d’observation représentative. Rollbackez le binding si des clients refusent la chaîne, si le mauvais hostname est servi ou si la disponibilité baisse. Ne rollbackez pas l’émission entière parce qu’un binding était incorrect.

Conclusion

Un renouvellement TLS App Service est une chaîne : émission, validation, version Key Vault, import App Service, binding du hostname et certificat réellement servi avec SNI. Une date d’expiration plus lointaine dans le portail ne prouve qu’un seul maillon.

La décision de production devient fiable quand le premier écart est explicite. Corrigez la validation si l’émission est bloquée, l’accès si le stockage ne peut pas se synchroniser, importez ou synchronisez si App Service ne possède pas le nouveau thumbprint, et ne rebindez qu’un candidat déjà validé. Conservez le thumbprint précédent tant que les probes externes n’ont pas prouvé le nouveau certificat end-to-end.