Certificats expirants : alertes proactives pour votre flotte

Un certificat TLS ou d'authentification 802.1X expiré peut couper un parc entier du réseau Wi-Fi d'entreprise sans le moindre avertissement préalable. Voici comment industrialiser la détection et les alertes avant que l'incident ne se produise.

Un certificat expiré, et c'est la panne réseau

Le 12.01.2024, une fiduciaire vaudoise de 45 postes voit ses MacBook perdre l'accès au Wi-Fi d'entreprise à 08h03. Le certificat client EAP-TLS déployé via MDM a expiré à minuit. Aucune alerte n'avait été configurée. Remédiation à la main, poste par poste : trois heures de productivité perdues, un client bancaire qui attend ses états financiers. Le coût direct dépasse 2 000 CHF en heures technicien, sans compter l'impact réputationnel.

Ce scénario se répète chaque semaine dans des PME romandes qui ont déployé un MDM sans configurer de pipeline de surveillance des certificats. Cet article détaille l'architecture d'alerte, les seuils à retenir, les intégrations MDM concrètes et la procédure de renouvellement en moins de 30 minutes.

Pourquoi les certificats expirent-ils sans prévenir

Le cycle de vie rarement documenté

Sur un parc Windows 11 23H2 ou macOS 14 Sonoma géré via MDM, les certificats sont typiquement déployés par profil de configuration. Leur durée de validité dépend de l'autorité émettrice :

Certificats d'authentification 802.1X émis par une PKI interne (Microsoft ADCS) : durée usuelle de 1 an, parfois 2 ans.
Certificats TLS serveur publics (Let's Encrypt, DigiCert) : 90 jours pour Let's Encrypt, 1 an pour les AC commerciales depuis 2020.
Certificats push MDM (APNs Apple) : renouvellement annuel obligatoire avant le 30 juin si vous utilisez Apple Push Notification Service.
Certificats d'enrollment MDM SCEP/NDES : durée configurable, souvent calquée sur la politique ADCS, typiquement 1 an.
Certificats de signature de code (Developer ID, Windows EV) : 1 à 3 ans selon le type.

La plupart des MDM (Intune, Jamf, FleetDM, Mosyle, Kandji) déploient ces certificats via des profils SCEP ou PKCS, mais ne génèrent pas nativement d'alerte opérationnelle à J-30 ou J-14. La responsabilité de la surveillance reste côté administrateur.

Les risques réels sur la flotte

L'expiration d'un certificat client 802.1X bloque l'authentification réseau sur tous les endpoints qui s'appuient sur EAP-TLS. Sur un parc de 80 MacBook en open space, la totalité des machines tombe simultanément. Sur Windows, l'expiration du certificat d'enrollment SCEP peut entraîner la perte de conformité dans Intune, déclenchant des politiques d'accès conditionnel qui bloquent Exchange Online ou SharePoint. L'expiration du certificat APNs MDM coupe toute capacité de push MDM vers les appareils Apple — impossible d'envoyer un profil, un wipe, ou une commande Lock.

Du point de vue de la nLPD, une interruption de service causée par un certificat expiré sur un système traitant des données personnelles peut constituer une violation de la disponibilité. Si l'incident dure plus de 72 heures et implique des données sensibles, une notification au PFPDT peut être requise selon l'article 24 nLPD.

Architecture de surveillance : trois couches complémentaires

Couche 1 — Inventaire MDM et requêtes planifiées

Tout MDM sérieux expose un inventaire des certificats installés sur les endpoints. Sur FleetDM (open source), la table certificates via osquery permet d'interroger en temps réel chaque endpoint :

SELECT common_name, not_valid_after, issuer FROM certificates WHERE not_valid_after < (strftime('%s','now') + 2592000);

Ce filtre remonte tous les certificats expirant dans les 30 prochains jours (2 592 000 secondes). Sur un parc de 50 endpoints macOS/Windows, cette requête planifiée en cron quotidien à 06h00 génère un rapport exportable en JSON ou CSV. FleetDM permet de configurer des policies qui passent en rouge dès qu'un certificat entre dans la fenêtre critique, avec alerte Slack ou e-mail.

Sous Intune, l'onglet Devices > Monitor > Certificates liste les certificats SCEP/PKCS déployés et leur date d'expiration. Il est possible d'exporter ce rapport et de le traiter via Power Automate pour déclencher un e-mail à J-60, J-30 et J-7.

Couche 2 — Surveillance externe des endpoints exposés

Les certificats TLS des services exposés (portail VPN SSL sur port TCP 443, reverse proxy, interface de gestion MDM, portail ADFS) doivent être surveillés depuis l'extérieur, indépendamment des agents MDM. Les outils de monitoring réseau (Zabbix, Nagios, Uptime Kuma en auto-hébergé) intègrent des sondes check_ssl_cert configurables avec des seuils :

Alerte WARNING à J-30 (30 jours avant expiration)
Alerte CRITICAL à J-14
Alerte PAGE (PagerDuty/SMS) à J-7

Pour un parc de 20 à 150 endpoints avec quelques services exposés, trois à dix sondes TCP suffisent. Le coût d'un Zabbix auto-hébergé sur un VPS à 15 CHF/mois est négligeable face à une heure de panne.

Couche 3 — Surveillance de la PKI interne (ADCS / Let's Encrypt)

Si vous opérez une PKI Microsoft (ADCS), le script PowerShell Get-CATemplate combiné à Get-IssuedRequest permet d'extraire tous les certificats émis avec leur date d'expiration. Un script planifié via Task Scheduler exporte ce rapport chaque nuit et l'envoie à l'équipe IT si des certificats tombent dans la fenêtre des 45 jours.

Pour Let's Encrypt, l'outil certbot renew --dry-run couplé au monitoring de la date dans /etc/letsencrypt/live/domaine/cert.pem (commande openssl x509 -enddate -noout) suffit. Let's Encrypt renouvelle automatiquement à J-30, mais il faut surveiller les échecs de renouvellement, pas seulement l'expiration.

Procédure de renouvellement sur flotte MDM : étape par étape

Lorsqu'une alerte se déclenche, la procédure suivante s'applique pour un certificat client 802.1X sur parc mixte macOS/Windows. Elle suppose un MDM centralisé avec SCEP intégré à ADCS.

Identification (DSI/RSSI, 5 min) : Confirmer via l'inventaire MDM la liste exacte des endpoints concernés, le CN du certificat, l'émetteur, la date d'expiration précise.
Vérification du template ADCS (Admin PKI, 10 min) : S'assurer que le template SCEP est valide, que la durée de renouvellement est configurée à 2 ans (pour limiter la fréquence), et que le compte de service NDES dispose des permissions d'enrôlement.
Mise à jour du profil MDM (DSI, 15 min) : Dans la console MDM, modifier le profil SCEP si nécessaire (Subject, SAN, Usage) et forcer un renouvellement via Push profile ou Renew certificate. Sur Intune : Devices > Configuration profiles > [profil SCEP] > Properties > Assignments, puis Sync forcé.
Vérification sur endpoints pilotes (DSI, 10 min) : Sur 3 à 5 machines représentatives, vérifier via le trousseau (macOS) ou le gestionnaire de certificats certmgr.msc (Windows) que le nouveau certificat est présent et valide.
Déploiement global et monitoring (DSI, 30-60 min) : Surveiller le tableau de bord MDM jusqu'à ce que 95 % des endpoints aient reçu le nouveau certificat. Documenter le déploiement avec timestamps dans le registre des incidents.
Mise à jour des seuils d'alerte (DSI/RSSI) : Ajuster les sondes de monitoring pour refléter la nouvelle date d'expiration. Si l'incident a révélé un angle mort, ajouter une sonde supplémentaire.

Pour le certificat APNs Apple, la procédure passe exclusivement par Apple Business Manager (Apple Business Manager ne fait pas partie de la liste blanche — ne pas lier) puis par la console MDM. Le renouvellement doit utiliser le même Apple ID que l'émission initiale, sinon tous les appareils MDM doivent être réenrollés. Cette contrainte justifie de créer un Apple ID dédié, associé à une adresse e-mail de service (ex. mdm-apns@entreprise.ch) et non à un compte personnel.

Seuils et politiques recommandés selon les référentiels

Les CIS Benchmarks pour macOS 14 et Windows 11 recommandent une gestion centralisée des certificats avec rotation documentée. Le NIST Cybersecurity Framework version 2.0 classe la surveillance des certificats dans la fonction Identify (ID.AM — Asset Management) et Protect (PR.IP — Information Protection Processes). Une politique de certificats alignée ISO 27001 (contrôle A.8.24 de la révision 2022) exige une procédure documentée de gestion du cycle de vie des clés cryptographiques.

Seuils pratiques pour une PME de 20-150 endpoints :

Certificats internes (ADCS, durée 1-2 ans) : alerte à J-45, renouvellement à J-30.
Certificats TLS publics (90 jours Let's Encrypt) : alerte à J-20, renouvellement automatisé via certbot/ACME.
Certificat APNs MDM (1 an) : rappel calendrier à J-60 et J-30, renouvellement manuel obligatoire.
Certificats de signature de code (1-3 ans) : alerte à J-60.
Certificats VPN/SSL gateway (1 an commercial) : alerte à J-45, coordination avec l'hébergeur.

Le NCSC publie des recommandations sur la gestion des identités numériques pour les PME suisses, incluant la gestion des certificats comme composante de la sécurité des accès. En cas d'incident majeur lié à un certificat (accès non autorisé, usurpation de service), le signalement au NCSC est recommandé via leur formulaire en ligne.

Cas pratique : cabinet d'ingénieurs à Fribourg, 65 endpoints

Contexte

Un bureau d'études en génie civil basé à Fribourg opère 65 endpoints : 40 postes Windows 11 23H2 fixes, 15 laptops macOS 14, 10 tablettes iPad Pro gérées via Apple Business Manager. Le parc est géré via un MDM hybride (Intune pour Windows, Jamf pour Apple). L'authentification Wi-Fi repose sur EAP-TLS avec des certificats clients émis par une PKI ADCS interne. La PKI est hébergée sur un serveur Windows Server 2022 on-premise. La durée de validité des certificats clients avait été configurée à 1 an lors du déploiement initial en mars 2022.

L'incident déclencheur

Le 05.03.2024, les 65 endpoints perdent simultanément l'accès au Wi-Fi d'entreprise à 00h00. Le certificat client SCEP avait expiré. Aucun système de monitoring n'était en place. La remédiation manuelle a nécessité 6 heures de travail pour deux techniciens (240 CHF/h chacun) : coût direct 2 880 CHF. S'y ajoutent les heures perdues des ingénieurs (15 personnes bloquées 2h à 100 CHF/h) : 3 000 CHF supplémentaires. Coût total de l'incident : ~5 880 CHF.

Architecture de surveillance déployée après incident

Étape 1 — Inventaire FleetDM en parallèle d'Intune/Jamf : Déploiement d'un agent FleetDM sur les 65 endpoints. Requête osquery planifiée chaque nuit à 05h30 :

SELECT common_name, not_valid_after, issuer, subject FROM certificates WHERE path = 'system' AND not_valid_after < (strftime('%s','now') + 3888000);

(3 888 000 secondes = 45 jours). Résultat exporté en JSON, parsé par un script Python qui envoie un e-mail récapitulatif à l'IT si la liste n'est pas vide.

Étape 2 — Politique FleetDM avec alerte Slack : Une policy FleetDM vérifie que chaque endpoint a au moins un certificat EAP-TLS valide pendant plus de 30 jours. Si la policy échoue, une alerte est postée dans le canal Slack #it-alerts avec le hostname, le CN du certificat et la date d'expiration.

Étape 3 — Monitoring externe (Zabbix) : Trois sondes SSL sur le portail VPN (TCP/443), l'interface de gestion MDM (TCP/8443) et le serveur ADCS web enrollment (TCP/443). Seuils : WARNING à J-30, CRITICAL à J-14. Notification par e-mail et SMS via Zabbix Media.

Étape 4 — Durée de validité ADCS portée à 2 ans : Modification du template SCEP dans ADCS pour émettre des certificats de 730 jours. Redéploiement de tous les certificats via Intune (profil SCEP, Renew before expiry configuré à 20 %). Sur macOS, Jamf profile SCEP reconfigured avec KeySize: 2048, ValidityPeriod: 730.

Résultat : Depuis mars 2024, aucun incident lié aux certificats. Le rapport quotidien FleetDM a détecté en août 2024 un certificat VPN expirant à J-28, renouvellement effectué en 20 minutes sans interruption de service. Coût annuel du dispositif de surveillance : environ 480 CHF (VPS Zabbix 15 CHF/mois + temps de configuration initial 12h à 120 CHF/h = 1 920 CHF amorti sur 3 ans → 640 CHF/an). ROI positif dès le premier incident évité.

Récapitulatif opérationnel

Inventorier : Extraire dès aujourd'hui la liste de tous les certificats du parc via MDM ou osquery (table certificates). Identifier les 10 certificats dont l'expiration est la plus proche.
Classifier : Distinguer certificats clients (802.1X), certificats TLS serveur, certificat APNs MDM, certificats de signature de code. Chaque catégorie a ses propres seuils d'alerte et procédures de renouvellement.
Configurer les seuils : J-45 pour certificats internes 1-2 ans ; J-20 pour Let's Encrypt 90 jours ; J-60 pour APNs et certificats 3 ans.
Automatiser les alertes : Requête osquery FleetDM ou export Intune + Power Automate. Alerte Slack/e-mail quotidienne si fenêtre d'alerte franchie. Ne pas compter sur la mémoire ou un calendrier manuel.
Surveiller les services exposés : Sondes TCP SSL sur tous les services accessibles depuis Internet (TCP/443, TCP/8443) via Zabbix, Nagios ou équivalent. Indépendant des agents MDM.
Documenter la procédure de renouvellement : Qui renouvelle, dans quel système, avec quelle autorité. Le renouvellement APNs doit être fait avec le même Apple ID que l'émission initiale.
Allonger les durées de validité ADCS : Passer les templates SCEP internes à 730 jours pour réduire la fréquence des opérations. Configurer le paramètre Renew before expiry à 15-20 % dans les profils MDM.
Tester annuellement : Simuler une expiration en environnement de test pour valider que la chaîne alerte → renouvellement → déploiement fonctionne en moins de 30 minutes.
Registre des incidents : Documenter chaque renouvellement avec date, CN, émetteur, technicien. Exigence de traçabilité dans le cadre ISO 27001 (A.8.24) et bonne pratique nLPD pour les systèmes traitant des données personnelles.
Revue trimestrielle : DSI + RSSI, 30 minutes, pour vérifier que tous les certificats connus sont dans l'inventaire et qu'aucun service nouvellement déployé n'a échappé à la surveillance.

SynGuard intègre nativement ces mécanismes de surveillance et d'alerte dans sa plateforme de gestion d'endpoints pour PME suisses, avec des tableaux de bord dédiés aux certificats et aux politiques de conformité.

Sources

Fédération suisse — nLPD (RS 235.1) — Texte consolidé de la nouvelle loi fédérale sur la protection des données, art. 24 (notification des violations).
Centre national pour la cybersécurité (NCSC) — Recommandations et signalement d'incidents pour PME suisses.
CIS Benchmarks — Center for Internet Security — Configurations de référence pour macOS 14 et Windows 11, incluant la gestion des certificats.
NIST Cybersecurity Framework 2.0 — Fonctions Identify et Protect, gestion des actifs cryptographiques.
Préposé fédéral à la protection des données et à la transparence (PFPDT) — Lignes directrices sur les obligations de notification et la sécurité des données personnelles.

Surveillance des certificats expirants : alertes proactives pour la flotte