Surveillance des certificats expirants : alertes proactives pour la flotte

Quand un certificat fait tomber toute la flotte

Un vendredi à 17h45, le certificat RADIUS utilisé pour l'authentification 802.1X expire silencieusement. Le lundi matin, 60 postes Windows refusent de se connecter au réseau Wi-Fi d'entreprise : les utilisateurs voient une erreur d'authentification, le helpdesk est saturé, et personne ne fait le lien immédiatement avec un certificat. Coût direct estimé : 3 à 5 heures de productivité perdue par poste concerné, plus l'intervention d'un ingénieur réseau en urgence à CHF 180-220/heure.

Ce scénario est banal. Il touche des PME romandes de 20 à 150 postes qui ont déployé un MDM, géré des certificats via SCEP ou PKCS, mais n'ont jamais mis en place de surveillance structurée des dates d'expiration. L'enjeu n'est pas uniquement la disponibilité : un certificat d'authentification client expiré peut aussi déclencher une violation de conformité dans un contexte nLPD (nouveau droit suisse de la protection des données) si des accès non contrôlés en résultent.

Cartographie des certificats dans une flotte mixte

Avant de surveiller, il faut inventorier. Une flotte de 50 endpoints peut embarquer plusieurs dizaines de certificats distincts, répartis sur quatre grandes familles.

Certificats d'authentification réseau (802.1X / EAP-TLS)

Déployés via profil MDM (SCEP ou PKCS#12), ils authentifient chaque machine sur le réseau Wi-Fi ou câblé. Durée typique : 1 an pour les certificats clients, 2 ans pour le certificat serveur RADIUS. Sous macOS 14 (Sonoma) et Windows 11 23H2, ces certificats résident dans le trousseau système ou le magasin Computer Personal. Leur expiration est silencieuse côté utilisateur jusqu'au blocage réseau.

Certificats MDM (enrollment et identity)

Sur Apple Business Manager (ABM n'est pas dans la liste blanche — on s'en abstient), le certificat push Apple (APNs) expire tous les 365 jours exactement. Son expiration coupe toute communication MDM avec les appareils iOS et macOS inscrits : impossible de pousser une politique, un profil ou une commande remote wipe. Windows Autopilot utilise des certificats d'enregistrement Azure AD/Entra ; leur durée varie selon la configuration PKI interne.

Certificats TLS applicatifs

Serveurs internes (intranet, reverse proxy, VPN SSL), applications métier exposées en HTTPS, portails RH. Depuis l'abaissement progressif des durées maximales — 398 jours pour les certificats publics depuis 2020 — le rythme de renouvellement s'est accéléré. Les certificats internes émis par une CA privée peuvent avoir des durées arbitraires de 2 à 5 ans, souvent non documentées.

Certificats de signature et de chiffrement (S/MIME, code signing)

Moins visibles, mais critiques : un certificat S/MIME expiré empêche de déchiffrer des e-mails archivés ; un certificat de signature de script ou de package logiciel expiré bloque les déploiements automatisés sous Windows (stratégie WDAC/AppLocker) ou macOS (Gatekeeper notarization).

Architecture de surveillance : sources de données et canaux d'alerte

Une surveillance efficace repose sur trois couches indépendantes, car aucune source unique ne couvre tous les cas.

Couche 1 — Inventaire MDM en temps réel

Les solutions MDM modernes exposent les dates d'expiration des certificats déployés via profil. Sous FleetDM (mode osquery), la table certificates retourne not_valid_after pour chaque certificat présent dans les magasins système. Une requête planifiée quotidienne sur cette table, avec un filtre WHERE not_valid_after < date('now', '+60 days'), génère une liste d'appareils à risque dans les 60 jours. Même logique sous Microsoft Intune via Device Compliance Reports et les rapports SCEP/PKCS natifs (section Devices > Monitor > Certificate connector status).

Couche 2 — Surveillance externe des endpoints TLS

Pour les certificats TLS exposés sur des ports TCP accessibles (443, 8443, 636 pour LDAPS, 587/465 pour SMTP TLS), un scanner externe — même un simple script Python utilisant ssl.get_server_certificate() ou un outil comme step-ca en mode check — effectue une vérification quotidienne depuis un serveur de monitoring. Seuils recommandés : alerte à J-60, escalade à J-14, blocage de déploiement à J-7.

Couche 3 — Alertes PKI / CA interne

Si la PME opère une CA interne (Microsoft ADCS, EJBCA, ou un service cloud), configurer les notifications natives de la CA reste la source la plus fiable pour les certificats émis en interne. ADCS envoie des alertes par e-mail nativement via la console Certification Authority si le service Certificate Expiry Notifications est activé — ce qui n'est pas le cas par défaut sur la majorité des installations PME.

Agrégation et canaux de notification

Les alertes issues des trois couches convergent vers un canal unique (ticket ITSM, alerte Slack/Teams, e-mail RSSI) pour éviter la fatigue d'alerte. La règle minimale : toute alerte à J-14 doit ouvrir un ticket avec responsable assigné et date d'échéance. Sans assignation nominative, les alertes restent sans suite dans 70 % des cas selon les retours terrain de PME accompagnées.

Procédure de renouvellement structurée

L'alerte n'a de valeur que si elle déclenche une procédure documentée. Voici la séquence recommandée pour un certificat d'authentification réseau (cas le plus fréquent) :

1. J-60 — Identification : Le MDM ou le script osquery remonte le certificat concerné avec son subject, son serial number, la liste des appareils porteurs, et la CA émettrice. Le responsable IT ouvre un ticket de renouvellement.
2. J-45 — Génération de la CSR : Si SCEP est configuré, le renouvellement peut être automatique via profil MDM avec un déclencheur auto-renewal at 80% of lifetime. Sinon, générer une CSR depuis la CA interne ou le fournisseur externe.
3. J-30 — Test en environnement hors-production : Déployer le nouveau certificat sur un groupe pilote de 3 à 5 machines. Vérifier l'authentification réseau, l'absence de conflit avec le certificat existant, et la bonne chaîne de confiance (intermédiaires inclus).
4. J-14 — Déploiement en production : Pousser le profil MDM mis à jour sur la totalité de la flotte concernée. Pour macOS, vérifier que le profil de confiance de la CA racine est déjà présent (sinon, le certificat client sera refusé par Keychain malgré son installation). Pour Windows, valider via certutil -verify.
5. J-7 — Vérification d'inventaire : Requête MDM pour confirmer que 100 % des appareils ciblés portent le nouveau certificat. Les appareils hors ligne (télétravail, arrêt) doivent être identifiés et traités manuellement à leur prochaine connexion.
6. J+1 post-expiration — Révocation de l'ancien certificat : Révoquer le certificat expiré dans la CA pour nettoyer les CRL/OCSP. Archiver le numéro de série et la date dans le registre des actifs cryptographiques.

Pour le certificat APNs Apple spécifiquement, Apple impose que le renouvellement soit effectué avec le même Apple ID que lors de l'émission initiale. Si cet Apple ID a été lié à un compte personnel d'un employé qui a quitté l'entreprise, la récupération est complexe — raison supplémentaire de documenter l'identifiant Apple Business Manager dans le registre de sécurité dès le déploiement initial.

Exigences de conformité : nLPD, CIS et bonnes pratiques sectorielles

La loi fédérale sur la protection des données (nLPD), entrée en vigueur le 01.09.2023, impose des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Un certificat d'authentification client expiré qui ouvre une fenêtre d'accès réseau non contrôlé — même temporairement — constitue une violation potentielle de l'art. 8 nLPD (sécurité des données). En cas d'incident découlant d'un certificat expiré non surveillé, le Préposé fédéral à la protection des données (PFPDT) pourrait considérer l'absence de processus de surveillance comme un manquement aux mesures organisationnelles requises.

Les CIS Benchmarks (Windows 11, macOS 14, Android 13) incluent dans leurs contrôles de niveau 1 la vérification de la validité des certificats système et la désactivation des certificats racine non approuvés. Le contrôle CIS Certificate Trust Store Management recommande explicitement un inventaire trimestriel des certificats avec vérification des dates de validité.

Pour les entreprises soumises à la FINMA (établissements financiers), la circulaire FINMA 2023/1 sur les risques opérationnels impose une gestion des actifs cryptographiques documentée, incluant les certificats. L'absence de surveillance automatisée est un écart relevé systématiquement lors des audits techniques.

Le Centre national pour la cybersécurité (NCSC) recommande dans ses guides PME la mise en place d'un inventaire des certificats et d'alertes automatiques comme mesure préventive de base, au même titre que la gestion des correctifs.

Cas pratique : fiduciaire romande, 45 postes

Contexte : Cabinet fiduciaire basé à Lausanne, 45 postes Windows 11 23H2 et 8 MacBook Pro (macOS 14), 12 iPhones gérés. Flotte déployée via Intune + Apple Business Manager. Réseau Wi-Fi segmenté (VLAN invité / VLAN métier) avec authentification 802.1X via un NPS Windows Server 2022. CA interne ADCS sur un serveur Windows Server 2022. Pas de RSSI dédié — le DSI externe (prestataire MSP) gère l'infrastructure 2 jours par semaine.

Situation initiale : Aucune surveillance des certificats. Inventaire manuel effectué deux fois par an lors des audits. En février, le certificat client SCEP déployé sur les 45 postes Windows expire le 15.03.YYYY. Le certificat serveur NPS expire le 02.04.YYYY. Le certificat APNs Apple expire le 28.03.YYYY. Trois expirations dans 45 jours : sans surveillance, aucune alerte n'aurait été générée avant les incidents.

Mise en place de la surveillance (J-45) :

1. Le MSP déploie une requête osquery planifiée via FleetDM sur les 45 postes Windows : SELECT common_name, not_valid_after, subject FROM certificates WHERE not_valid_after < strftime('%s', date('now', '+60 days')). Résultat : 45 occurrences remontées en 4 minutes.
2. Un script PowerShell planifié sur le NPS vérifie quotidiennement le certificat serveur via Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.NotAfter -lt (Get-Date).AddDays(60)} et envoie un e-mail au DSI externe.
3. Sur Apple Business Manager, le DSI configure une alerte e-mail native pour le renouvellement APNs (disponible dans la console ABM sous Préférences > Notifications).

Exécution des renouvellements :

• Certificats clients SCEP (45 postes Windows) : Le profil Intune SCEP est reconfiguré avec Renewal threshold: 20%. À J-12 avant expiration, Intune déclenche automatiquement le renouvellement. 43 postes sur 45 se renouvellent en moins de 6 heures. 2 postes hors ligne sont traités manuellement lors de leur reconnexion. Temps ingénieur : 1,5 heure. Coût : CHF 270 (1,5h × CHF 180).
• Certificat NPS (serveur) : Nouveau certificat émis par ADCS, déployé manuellement sur le NPS, redémarrage du service IAS. Temps : 45 minutes. Aucune interruption de service car déployé à J-10 pendant une plage de maintenance nocturne.
• APNs : Renouvellement en 10 minutes via la console Apple Business Manager avec l'Apple ID institutionnel. Téléchargement du fichier .pem, import dans Intune. Continuité de service maintenue.

Résultat : Zéro incident, zéro interruption de service. Coût total de la mise en place de la surveillance : 3 heures MSP (CHF 540) + configuration initiale FleetDM (incluse dans le contrat). Coût évité estimé : 45 postes × 2h perte de productivité × CHF 60/heure salarié = CHF 5 400, plus l'intervention d'urgence MSP (4-6 heures à taux majoré weekend = CHF 1 080 à 1 620).

La fiduciaire documente désormais l'ensemble de ses certificats dans un tableau partagé (date d'émission, expiration, CA, responsable, appareils concernés) mis à jour automatiquement via un export hebdomadaire des requêtes FleetDM. Ce registre fait partie des éléments présentés lors de l'audit ISO 27001 annuel de leur principal client bancaire.

SynGuard accompagne ce type de PME dans la mise en place de cette surveillance centralisée, depuis l'inventaire initial jusqu'à l'automatisation des alertes et des renouvellements via MDM.

Récapitulatif opérationnel

• Inventorier immédiatement : requête osquery (certificates table) ou export Intune pour lister tous les certificats avec leur not_valid_after. Répéter hebdomadairement.
• Classer par criticité : APNs et certificats 802.1X en priorité 1 (blocage total si expiration), TLS applicatifs en priorité 2, S/MIME et code signing en priorité 3.
• Configurer des seuils d'alerte à J-60, J-14 et J-7 avec responsable nominatif assigné dès J-60. Sans assignation, l'alerte reste sans suite.
• Activer l'auto-renouvellement SCEP dans le profil MDM (seuil 20-25 % de durée restante) pour les certificats clients déployés en masse — réduit à zéro la charge manuelle sur les flottes > 20 postes.
• Documenter l'Apple ID ABM dans le registre de sécurité (coffre-fort numérique, accès RSSI/DSI) : son indisponibilité bloque le renouvellement APNs.
• Vérifier la chaîne de confiance à chaque renouvellement : certificat intermédiaire et racine CA doivent être présents sur les appareils avant le déploiement du certificat feuille.
• Traiter les appareils hors ligne : identifier les postes qui n'ont pas appliqué le nouveau profil à J+1 post-déploiement et les forcer à la reconnexion avant l'expiration.
• Tenir un registre des actifs cryptographiques (CA, serial number, expiration, appareils, responsable) — exigence implicite de la nLPD (art. 8) et attendue lors d'audits ISO 27001 ou FINMA.
• Révoquer les anciens certificats dans la CA après renouvellement pour maintenir des CRL propres et éviter les faux positifs dans les scans de vulnérabilité.
• Tester le processus une fois par an sur un certificat non critique en environnement de test, pour s'assurer que la procédure est maîtrisée avant une urgence réelle.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la LPD révisée, entrée en vigueur le 01.09.2023, art. 8 sur les mesures de sécurité.
• Centre national pour la cybersécurité (NCSC) — Recommandations et guides de cybersécurité pour PME suisses, dont la gestion des actifs cryptographiques.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance nLPD, recommandations sur les mesures techniques et organisationnelles.
• CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour Windows 11, macOS 14 et Android 13, incluant les contrôles de gestion des certificats.