Certificats expirants : alertes proactives MDM

Un certificat Wi-Fi EAP-TLS expiré à 02h00 un lundi matin, et 80 postes Windows sont exclus du réseau d'entreprise avant l'ouverture des bureaux. Voici comment automatiser la surveillance des certificats sur une flotte mixte et éviter ces interruptions prévisibles.

Un certificat qui expire, c'est une panne annoncée

La majorité des incidents liés aux certificats numériques dans les PME ne résultent pas d'une attaque : ils résultent d'un oubli. Un certificat SCEP déployé via MDM il y a 12 mois, un certificat client EAP-TLS renouvelé manuellement il y a deux ans, un certificat de signature de code pour une application interne — tous ont une date d'expiration précise, rarement suivie de façon systématique. Résultat : interruption de service, exclusion du réseau 802.1X, ou blocage d'accès VPN, parfois à une heure critique.

Sur une flotte de 50 à 150 endpoints (macOS, Windows, iOS/Android), plusieurs dizaines de certificats coexistent : certificats d'identité utilisateur, certificats machine pour l'authentification réseau, certificats de confiance pour les proxys TLS, certificats push APNs pour le MDM lui-même. Chaque catégorie a son cycle de vie, son autorité émettrice, et son vecteur de renouvellement. L'absence d'une supervision centralisée transforme chaque expiration en incident potentiel.

Cartographie des certificats sur une flotte mixte

Certificats critiques par type d'endpoint

Sur macOS 14 (Sonoma), les certificats MDM-managed sont visibles dans le profil de configuration du Trousseau système. Les certificats déployés via un profil de configuration Apple Business Manager (ABM — domaine privé, non lié ici) s'inscrivent dans le keychain système et peuvent être interrogés via security find-certificate ou via l'API MDM native. Les certificats SCEP (CIS Benchmark macOS recommande leur rotation avant J-30) sont renouvelés automatiquement si le profil SCEP est correctement configuré avec un payload PayloadType: com.apple.security.scep et une URL de challenge valide.

Sur Windows 11 23H2, les certificats sont stockés dans plusieurs magasins distincts : Personal (utilisateur et machine), Trusted Root Certification Authorities, Intermediate Certification Authorities. Windows Autopilot déploie les certificats via des profils Intune (SCEP ou PKCS), mais le suivi de l'état de renouvellement repose sur le rapport de conformité du device. Le composant certutil -viewstore permet une inspection locale ; côté MDM, l'API Graph expose l'état via deviceManagement/managedDevices/{id}/managedDeviceOverview.

Sur Android (Android Enterprise, profil professionnel), les certificats sont distribués via KeyChain API ou via le profil MDM. Les certificats Wi-Fi EAP-TLS et VPN sont les plus sensibles : leur expiration coupe silencieusement l'accès réseau sans notification visible à l'utilisateur. FleetDM (pour les flottes Linux/macOS) expose les certificats via la table osquery certificates, interrogeable avec une requête schedulée.

Le cas particulier du certificat APNs

Le certificat Apple Push Notification service (APNs) est probablement le plus critique d'une flotte Apple managée : s'il expire, le MDM perd la capacité d'envoyer des commandes à tous les appareils iOS et macOS de la flotte simultanément. Il a une durée de validité d'exactement 365 jours et doit être renouvelé manuellement sur le portail Apple Push Certificates Portal avec le même identifiant Apple Business Manager que celui utilisé lors de la création initiale. Un changement d'identifiant impose un réenrôlement complet de la flotte — coût opérationnel significatif pour 80 appareils. Planifier le renouvellement à J-60 est le seuil raisonnable.

Architecture de surveillance : trois niveaux d'alerte

Niveau 1 — Inventaire automatisé

La base est un inventaire continu des certificats présents sur chaque endpoint. Sur une flotte avec un MDM capable d'interroger l'état des profils (Intune, Jamf, FleetDM), configurez une remontée d'inventaire toutes les 24 heures maximum. La table osquery certificates retourne notamment not_valid_after (timestamp Unix), common_name, issuer, et path (magasin). Une requête schedulée simple :

SELECT common_name, issuer, not_valid_after,
  datetime(not_valid_after, 'unixepoch') AS expiry_date
FROM certificates
WHERE not_valid_after < strftime('%s','now','+60 days')
  AND path NOT LIKE '%System Roots%';

Cette requête remonte tous les certificats qui expirent dans les 60 prochains jours, en excluant les racines système (qui ont des cycles de vie pluriannuels gérés par l'éditeur). Le résultat alimente un dashboard central ou un SIEM.

Niveau 2 — Seuils d'alerte différenciés

Tous les certificats ne méritent pas la même urgence. Un découpage opérationnel efficace :

J-60 : alerte informationnelle au responsable IT. Vérification du processus de renouvellement, identification du propriétaire du certificat (utilisateur, service, système).
J-30 : alerte de niveau moyen (ticket ITSM créé automatiquement, assigné). Lancement du renouvellement si manuel. Pour les certificats SCEP, vérification que le renouvellement automatique est fonctionnel (test via MDM check-in).
J-14 : alerte haute. Si le renouvellement n'est pas confirmé, escalade vers le DSI ou le RSSI. Sur Intune, le rapport Device compliance doit afficher le certificat comme Not yet expired.
J-7 : alerte critique. Intervention manuelle obligatoire. Notification aux utilisateurs concernés si l'impact est prévisible (coupure VPN, Wi-Fi).

Ces seuils sont cohérents avec les recommandations du CIS Benchmarks pour la gestion des certificats dans les environnements entreprise.

Niveau 3 — Automatisation du renouvellement

Pour les certificats SCEP distribués via MDM, le renouvellement peut être entièrement automatique si l'infrastructure PKI (ADCS, EJBCA, ou PKI cloud) est opérationnelle et que le challenge SCEP est valide. Vérifiez que le paramètre SubjectAltName est cohérent entre l'ancienne et la nouvelle émission — une divergence entraîne un rejet silencieux côté 802.1X. Pour les certificats PKCS#12 (P12) distribués manuellement, il n'existe pas d'automatisation native : la surveillance proactive est l'unique filet de sécurité.

Implications légales et réglementaires suisses

La nouvelle Loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose aux responsables du traitement de mettre en œuvre des mesures techniques et organisationnelles appropriées pour garantir la sécurité des données. Un certificat TLS expiré sur un serveur traitant des données personnelles — par exemple, un portail RH ou un ERP accessible via HTTPS — constitue une mesure de sécurité défaillante. Si cette défaillance entraîne une violation de données, la notification au Préposé fédéral à la protection des données et à la transparence (PFPDT) dans un délai de 72 heures devient obligatoire dès que la violation présente un risque élevé pour les personnes concernées.

Pour les entreprises soumises à la réglementation FINMA (banques, assurances, gestionnaires de fortune), la circulaire FINMA 2023/1 sur les risques opérationnels exige une gestion documentée du cycle de vie des certificats comme composante du contrôle des accès. Une expiration non détectée sur un système de production peut être relevée lors d'un audit comme défaillance de contrôle interne.

La surveillance proactive des certificats n'est donc pas uniquement une bonne pratique IT : sur un périmètre traitant des données personnelles ou financières, c'est une exigence de conformité documentable.

Intégration dans le processus MDM : procédure opérationnelle

Inventaire initial : Exporter la liste complète des certificats de la flotte via l'API MDM ou osquery. Identifier les émetteurs (CA interne, Let's Encrypt, DigiCert, Apple, Microsoft), les durées de validité standard, et les propriétaires techniques.
Classement par criticité : Distinguer les certificats d'authentification réseau (EAP-TLS, VPN), les certificats de gestion MDM (APNs, MDM enrollment), les certificats d'application (HTTPS interne, signature), et les certificats utilisateur (S/MIME, smartcard).
Configuration des alertes : Paramétrer les requêtes osquery ou les rapports MDM avec les seuils J-60/J-30/J-14/J-7. Configurer les canaux de notification (e-mail, canal Teams/Slack interne, ticket ITSM).
Vérification du renouvellement automatique : Pour chaque profil SCEP actif, valider que le renouvellement automatique fonctionne en testant sur un appareil de staging. Documenter le résultat dans le registre des configurations.
Procédure de renouvellement manuel : Rédiger une runbook spécifique par type de certificat non automatisé (APNs, certificats wildcard, P12 applicatifs). Inclure les étapes, les acteurs (DSI, PKI admin, fournisseur externe), et les délais estimés.
Test de détection : Simuler une expiration imminente sur un endpoint de test et vérifier que l'alerte remonte dans les délais configurés. Documenter le test et son résultat.
Revue trimestrielle : Vérifier que l'inventaire est complet (nouveaux appareils, nouveaux certificats applicatifs), que les runbooks sont à jour, et que les responsables techniques sont toujours valides.

Cas pratique : fiduciaire romande, 45 endpoints

Contexte : Une fiduciaire basée à Lausanne, 38 collaborateurs, 45 endpoints (28 Windows 11, 12 MacBook Pro macOS 14, 5 iPad Pro iOS 17). Infrastructure mixte : domaine Active Directory on-premise avec ADCS pour la PKI interne, Intune pour la gestion Windows, MDM tiers pour Apple. Accès réseau Wi-Fi via 802.1X EAP-TLS avec certificats machine (durée de validité : 1 an, émis par la CA interne). VPN SSL avec certificats clients (durée : 2 ans). Un certificat APNs pour la flotte Apple.

Incident initial : Le 03.03.2024, 7 postes Windows refusent la connexion Wi-Fi à l'ouverture. Cause : les certificats EAP-TLS machine ont expiré le 02.03.2024 à 23h59. Ils avaient été émis le 02.03.2023 sans renouvellement automatique configuré (le profil Intune SCEP pointait vers une URL NDES incorrecte après une migration de serveur en octobre 2023). Impact : 7 collaborateurs sans réseau pendant 2h45, intervention d'urgence du prestataire IT à CHF 185/heure (3 heures facturées = CHF 555), sans compter le temps interne DSI (4 heures à CHF 120/h estimé = CHF 480). Coût total incident : environ CHF 1 035, hors pertes de productivité.

Remédiation et mise en place de la surveillance :

Audit PKI complet (J+1) : Le DSI inventorie tous les certificats via certutil -store My sur chaque poste et via le rapport Intune Device configuration — Certificate profiles. Résultat : 45 certificats EAP-TLS machine, 38 certificats VPN client, 1 APNs (expire le 14.09.2024 — découverte critique lors de l'audit). Acteurs : DSI, admin Intune.
Correction de l'URL NDES (J+1) : Mise à jour du profil SCEP Intune avec l'URL NDES correcte. Déploiement forcé sur les 45 postes Windows via Intune sync. Vérification via rapport de conformité à J+2.
Activation des alertes Intune (J+3) : Configuration d'un rapport planifié Intune sur les profils de certificats avec filtre NotAfter < now + 30 days, envoyé par e-mail chaque lundi matin au DSI et au prestataire IT.
Requête osquery pour macOS (J+5) : Déploiement d'une requête schedulée sur les 12 MacBook via le MDM Apple, remontant tous les certificats expirant dans les 60 jours. Les résultats sont agrégés dans un tableau de bord partagé (Google Sheets via webhook, mise à jour quotidienne).
Renouvellement APNs planifié (J+7) : Renouvellement du certificat APNs sur le portail Apple Push Certificates Portal à J-45 de l'expiration (31.07.2024), en utilisant l'identifiant Apple ABM d'origine. Durée de l'opération : 20 minutes. Documenté dans le registre de configuration.
Runbook rédigé et testé (J+14) : Procédure documentée pour chaque type de certificat : SCEP Intune, APNs, VPN P12. Test de simulation sur un poste de staging le 17.03.2024 : l'alerte J-30 s'est déclenchée correctement à 08h00.

Résultat à 6 mois : Zéro incident lié aux certificats entre le 03.03.2024 et le 30.09.2024. Deux renouvellements préventifs traités sans interruption de service (EAP-TLS en juin, VPN en août). Temps de gestion mensuel estimé : 45 minutes. ROI de la démarche : positif dès le premier trimestre.

Récapitulatif opérationnel

Inventoriez dès maintenant l'ensemble des certificats de votre flotte (osquery, Intune, MDM Apple) — incluez APNs, EAP-TLS, VPN, HTTPS interne, S/MIME.
Identifiez le certificat APNs de votre MDM Apple et vérifiez sa date d'expiration. S'il expire dans moins de 60 jours, planifiez le renouvellement immédiatement.
Configurez des alertes à J-60, J-30, J-14 et J-7 sur tous les certificats critiques, avec escalade automatique vers le DSI/RSSI à J-14.
Vérifiez le renouvellement automatique SCEP sur un endpoint de staging après chaque migration d'infrastructure (URL NDES, serveur ADCS, CA intermédiaire).
Rédigez un runbook par type de certificat non automatisé : acteurs, étapes, délais, contacts fournisseur. Stockez-le dans votre CMDB ou wiki interne.
Excluez les racines système de vos alertes (Apple Root CA, Microsoft Root CA) — elles sont gérées par l'éditeur via les mises à jour OS, pas par votre PKI.
Documentez chaque renouvellement dans un registre (date, certificat, émetteur, responsable, durée de validité nouvelle) — utile en cas d'audit nLPD ou FINMA.
Testez la détection au moins une fois par trimestre en simulant une expiration imminente sur un endpoint hors production.
Incluez la gestion des certificats dans votre procédure de changement (change management) : toute migration de serveur, de CA ou d'URL NDES doit déclencher une vérification des profils SCEP actifs.

SynGuard intègre la surveillance des certificats dans son module de gestion de conformité endpoint, avec agrégation des alertes pour les flottes mixtes macOS/Windows/Android.

Sources

Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD, en vigueur depuis le 01.09.2023, base légale pour les exigences de sécurité des données.
Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance suisse pour la protection des données, compétente pour les notifications de violations.
Centre national pour la cybersécurité (NCSC) — Recommandations et alertes pour les PME suisses sur la gestion des risques informatiques.
CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour macOS, Windows et Android, incluant les pratiques de gestion des certificats.

Surveillance des certificats expirants : alertes proactives pour votre flotte