Santé du certificat de signature SAML dans Microsoft Entra

Certificat de signature SAML Entra expiré : ce que cela signifie

Quand un certificat de signature SAML Entra est expiré, la connexion fédérée pour cette application tombe en panne pour tout le tenant — non pas à cause d'une attaque, mais à cause d'une tâche administrative de routine que personne n'a planifiée. Chaque application d'entreprise configurée pour l'authentification unique fédérée (SSO) via SAML dans Microsoft Entra ID repose sur un certificat de signature : Entra ID utilise sa clé privée pour signer cryptographiquement les assertions SAML qu'il émet, et le fournisseur de services valide ces assertions à l'aide de la clé publique correspondante. C'est l'ancrage de confiance de toute la relation de fédération — si le certificat est invalide, l'assertion ne vaut rien pour le fournisseur de services, quelle que soit la justesse du reste du flux d'authentification.

La « santé du certificat » couvre trois états de risque distincts mais liés, suivis dans le catalogue de vulnérabilités EtcSec pour les applications Azure :

Expiré — la période de validité du certificat est déjà dépassée. C'est une panne fonctionnelle, pas seulement une faiblesse de sécurité.
Expiration proche — le certificat expirera dans les 30 jours et aucun renouvellement n'a été préparé.
Durée de vie longue — le certificat a été émis avec une fenêtre de validité excessivement longue (Entra ID applique par défaut trois ans), ce qui élargit le rayon d'impact si la clé privée est un jour mal gérée, et augmente la probabilité que la personne responsable de la rotation ait depuis quitté l'organisation, changé de poste, ou simplement oublié.

Par défaut, lorsque vous configurez le SSO basé sur SAML pour une application de la galerie ou hors galerie, Entra ID génère automatiquement un certificat auto-signé valide trois ans (Microsoft Learn). Contrairement à un secret d'application dont la courte durée de vie par défaut impose une attention fréquente, un certificat SAML de trois ans est facile à configurer une fois puis à oublier — jusqu'à ce qu'il expire silencieusement.

Comment le certificat sous-tend la connexion fédérée

Lorsqu'Entra ID agit comme fournisseur d'identité (IdP) pour une application SAML, le flux de connexion dépend de l'état du certificat à deux moments :

Entra ID signe l'assertion SAML (ou la réponse) avec la clé privée du certificat de signature actif sur le principal de service de l'application d'entreprise.
Le fournisseur de services valide cette signature par rapport au certificat public qu'il a enregistré (téléversé manuellement ou récupéré dynamiquement depuis l'URL des métadonnées de fédération de l'application).

Si le certificat utilisé par Entra ID pour signer a expiré, Entra ID ne cesse pas de signer avec celui-ci — il continue d'utiliser le certificat marqué comme actif. C'est le fournisseur de services qui rejette l'assertion dès qu'il constate que le certificat n'est plus dans sa fenêtre de validité, et ce rejet est ce que les utilisateurs vivent comme un échec de connexion (Microsoft Learn). Autrement dit : Entra ID ne « remarque » pas l'expiration et ne bloque pas la connexion de manière proactive — la panne se manifeste en aval, au niveau de l'application, et seulement après que les utilisateurs commencent à la rencontrer.

Sondage des métadonnées et notifications par e-mail

Deux mesures d'atténuation existent selon les capacités de l'application :

Sondage des métadonnées de fédération. Pour les applications qui le prennent en charge, Entra ID vérifie les métadonnées de fédération de l'application environ 35 jours avant l'expiration du certificat de signature ; si un nouveau certificat y est découvrable, aucune intervention manuelle ni notification n'est nécessaire (Microsoft Learn).
Notifications par e-mail. Pour tout le reste, Entra ID envoie un e-mail aux adresses de notification configurées sur l'application d'entreprise 60, 30 et 7 jours avant l'expiration, depuis [email protected] — jusqu'à cinq adresses, par défaut uniquement l'administrateur qui a initialement configuré le SSO (Microsoft Learn).

Ces deux mesures dépendent d'une configuration correcte en amont, et toutes deux sont couramment négligées : le sondage des métadonnées ne fonctionne que si l'application le prend réellement en charge et l'exploite, et la liste de notification est trivialement laissée à la boîte mail d'un seul administrateur parti depuis.

⚠️

⚠️ Avertissement : Si la validation de l'expiration du certificat est désactivée côté application et qu'un nouveau certificat est créé avant la fenêtre de maintenance planifiée pour la bascule, Entra ID peut basculer automatiquement vers ce certificat valide mais pas encore téléversé, avant l'heure prévue — et comme le fournisseur de services ne l'a pas encore reçu, cela provoque une panne d'application plutôt qu'une correction silencieuse. La recommandation de Microsoft est d'attendre la fenêtre de maintenance avant de créer le nouveau certificat, et de garder la validation d'expiration activée côté fournisseur de services (Microsoft Learn).

Ce qui casse quand le certificat expire ou traîne trop longtemps

L'impact d'un certificat de signature SAML expiré porte sur la disponibilité, pas sur la confidentialité : la connexion fédérée pour cette application échoue pour tous les utilisateurs jusqu'à ce que le certificat soit renouvelé et réactivé des deux côtés. Pour une application SaaS métier utilisée dans tout le tenant, c'est une panne complète déclenchée uniquement par un oubli administratif, pas par une action d'attaquant.

Les certificats à longue durée de vie portent un risque différent, plus discret. Une fenêtre de validité de trois ans (ou plus) signifie :

La rotation se produit assez rarement pour que le processus manuel — générer, télécharger, téléverser vers le SP, activer, vérifier, nettoyer l'ancien certificat — soit mal maîtrisé à chaque fois, augmentant le risque d'erreur pendant la rotation elle-même.
Dérive de propriété : l'administrateur qui l'a configuré peut ne plus être dans l'organisation au moment du renouvellement.
Une fenêtre plus longue d'exposition de la clé privée si le certificat ou son export est un jour mal géré, sans rafraîchissement forcé.

Les propres recommandations de Microsoft aux éditeurs (ISV) qui construisent des intégrations SAML reconnaissent directement ce problème, notant que la bascule manuelle devient « intenable » à grande échelle à mesure que les durées de vie des certificats tendent à raccourcir dans l'ensemble du secteur, et recommande que les applications prennent en charge la bascule automatisée basée sur les métadonnées avec des certificats de signature primaire/secondaire, spécifiquement pour supprimer la fragilité opérationnelle des durées de vie longues et gérées manuellement (Microsoft Learn).

C'est aussi pourquoi cet écart compte du point de vue de la couverture : le cycle de vie des certificats SAML est un risque distinct de l'hygiène des permissions applicatives. Un risque connexe mais différent de la catégorie Applications — les enregistrements d'applications sur-privilégiés avec des permissions déléguées excessives — est couvert dans Azure App Registrations : applications sur-privilégiées du tenant ; la santé des certificats est une préoccupation orthogonale, centrée sur la disponibilité, au sein de la même catégorie.

Détection : repérer les certificats SAML expirants et à durée de vie trop longue

N'attendez pas une vague de tickets du support pour découvrir qu'un certificat a expiré. Entra ID expose l'état des certificats via plusieurs canaux :

Signal	Où	Ce qu'il faut chercher
Statut d'expiration du certificat	Centre d'administration Entra → Applications d'entreprise → [App] → Authentification unique → Certificats SAML	Statut, date d'expiration et empreinte de chaque certificat (actif et inactif)
`keyCredentials`, `passwordCredentials`	Objet `servicePrincipal` de Microsoft Graph	`endDateTime` dans le passé ou dans les 30 prochains jours ; plusieurs identifiants avec un état actif ambigu
`preferredTokenSigningKeyThumbprint`	Objet `servicePrincipal` de Microsoft Graph	Confirme avec quel certificat Entra ID signe réellement — vérifier qu'il correspond à celui téléversé chez le fournisseur de services
Recommandation Renouveler les identifiants de principal de service expirants	Centre d'administration Entra → Vue d'ensemble → Recommandations, ou Graph `/beta/directory/recommendations` (`servicePrincipalKeyExpiry`)	Signale tout identifiant de principal de service expirant dans les 30 jours, pour tout le tenant, sans avoir à vérifier application par application (Microsoft Learn)
Journaux d'audit	Journaux d'audit Microsoft Entra — Service : Core Directory, Catégorie : ApplicationManagement, Activité : Update Application – Certificates and secrets management / Update Service principal	Identifiant ajouté en dehors d'une fenêtre de changement connue, ou aucune mise à jour d'identifiant enregistrée à l'approche de l'expiration (Microsoft Learn)
Journaux de connexion	Journaux de connexion Microsoft Entra, filtrés sur l'application concernée	Un pic d'échecs de connexion concentré sur une seule application est le symptôme opérationnel ; des références tierces de dépannage SAML (par ex. le guide d'erreurs Entra SAML de SSOJet) associent couramment ce mode de panne au code `AADSTS50008` (InvalidSamlToken) côté relying party — à traiter comme un signal à vérifier côté certificat, pas comme une certitude, puisque le même code peut avoir d'autres causes

💡

💡 Astuce : Interrogez keyCredentials et passwordCredentials sur l'ensemble des servicePrincipal du tenant plutôt que de vérifier les applications une par une — c'est exactement l'audit que recommandent les propres consignes de sécurité opérationnelle de Microsoft pour repérer les longues fenêtres d'expiration d'identifiants avant qu'elles ne deviennent une panne (Microsoft Learn).

Pour un tour d'horizon plus large de la façon de structurer une revue de sécurité Entra complète au-delà des seuls certificats, voir Comment auditer la sécurité de Microsoft Entra ID. Pour un durcissement des paramètres par défaut à l'échelle du tenant qui réduit l'exposition en complément de l'hygiène des certificats, voir Durcissement du tenant Azure : corriger les paramètres par défaut non sécurisés.

Remédiation : renouveler sans interruption de service

La séquence de renouvellement documentée par Microsoft existe spécifiquement pour éviter une panne pendant la rotation — sauter des étapes ou les faire dans le désordre est la manière la plus courante dont les équipes transforment un renouvellement planifié en incident non planifié.

Étape 1 — Créer le nouveau certificat en avance

Créez le nouveau certificat avec une date d'expiration qui chevauche la validité restante du certificat actuel, via Applications d'entreprise → [App] → Authentification unique → Certificats SAML → Nouveau certificat. Il est enregistré comme Inactif — cette étape seule ne provoque aucune perturbation (Microsoft Learn).

Étape 2 — Le téléverser d'abord chez le fournisseur de services

Téléchargez puis téléversez le nouveau certificat chez le fournisseur de services, dans le format d'encodage spécifié par le guide de configuration SSO de l'application, avant de l'activer dans Entra ID.

Étape 3 — Activer, vérifier, puis nettoyer

Activez le nouveau certificat dans Entra ID (menu … du nouveau certificat → Rendre le certificat actif) — cela marque automatiquement l'ancien certificat comme inactif. Vérifiez que la connexion fonctionne de bout en bout pour l'application avant de considérer la rotation comme terminée, puis supprimez l'ancien certificat une fois la vérification faite afin qu'il ne puisse pas être réactivé par erreur plus tard.

# Microsoft Graph PowerShell — inspecter l'état actuel du certificat de signature SAML d'un principal de service
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -ServicePrincipalId "<service-principal-object-id>" `
    -Property "keyCredentials,preferredTokenSigningKeyThumbprint" |
    Select-Object -ExpandProperty KeyCredentials |
    Select-Object DisplayName, Usage, StartDateTime, EndDateTime

Pour ajouter un nouveau certificat de signature de jeton par programmation, utilisez l'action Graph servicePrincipal addTokenSigningCertificate, puis définissez preferredTokenSigningKeyThumbprint sur l'empreinte du nouveau certificat pour en faire celui avec lequel Entra ID signe (Microsoft Learn — Configurer le SSO SAML via Microsoft Graph).

✅ Remarque : Comblez l'écart de durée de vie longue en même temps que tout renouvellement. Fixez l'expiration du nouveau certificat à une fenêtre plus courte et délibérée plutôt que d'accepter les trois ans par défaut, et planifiez le prochain renouvellement suffisamment à l'avance pour éviter une nouvelle précipitation.

Prévenir la récidive

Au-delà du certificat lui-même, deux contrôles à faible effort évitent la récidive :

Renseignez le champ adresses e-mail de notification de chaque application fédérée avec une liste de diffusion, pas la boîte mail d'un individu — jusqu'à cinq adresses sont prises en charge, et Entra ID y envoie les alertes à 60/30/7 jours (Microsoft Learn).
Traitez la recommandation Renouveler les identifiants de principal de service expirants de la page Vue d'ensemble du centre d'administration Entra comme une vérification permanente à l'échelle du tenant, plutôt que de compter sur la mémoire application par application.

Pour les risques liés aux permissions applicatives qui coexistent souvent avec une mauvaise configuration des certificats sur les mêmes applications d'entreprise, voir OAuth Consent Phishing : comment les applications malveillantes contournent le vol de mot de passe. Pour les contrôles d'accès conditionnel plus larges qui régissent la manière dont les applications fédérées peuvent être atteintes, voir Failles d'accès conditionnel Entra ID.

Comment EtcSec détecte cela

L'audit Azure d'EtcSec vérifie l'état du certificat de signature SAML de chaque application d'entreprise à chaque scan du tenant. SAML_CERTIFICATE_EXPIRED signale toute application dont le certificat de signature actif a déjà expiré — un constat critique, impactant la disponibilité, puisque la connexion fédérée pour cette application est activement cassée. SAML_CERTIFICATE_EXPIRING_SOON signale les certificats proches de l'expiration afin que le renouvellement puisse être planifié plutôt que précipité, et SAML_CERTIFICATE_LONG_LIFETIME signale les certificats émis avec une fenêtre de validité excessive, afin de la raccourcir à la prochaine rotation plutôt que de réinitialiser la même horloge pluriannuelle.

ℹ️

ℹ️ Remarque : EtcSec vérifie automatiquement cette vulnérabilité lors de chaque audit Azure. Lancez un audit gratuit pour vérifier la posture de vos certificats SAML sur l'ensemble de vos applications fédérées.