Surveillance des certificats expirants : alertes proactives pour votre flotte

Un certificat silencieux peut coûter une journée de production

Le lundi matin, les 60 postes Windows d'un bureau d'ingénierie lausannois ne peuvent plus se connecter au réseau Wi-Fi d'entreprise. Le certificat EAP-TLS émis par l'AC interne a expiré le week-end précédent : aucune alerte, aucun ticket préventif. La remédiation — renouvellement du certificat, push MDM, reconnexion manuelle sur les machines hors domaine — mobilise deux ingénieurs pendant six heures. Coût direct : environ 2 400 CHF en temps interne, sans compter l'impact sur les délais projet. Ce scénario est récurrent parce que la gestion des certificats reste en grande partie manuelle dans les PME suisses de 20 à 150 endpoints.

Périmètre et typologies de certificats à surveiller

Certificats d'infrastructure réseau

Les certificats les plus critiques sont ceux qui bloquent l'accès au réseau dès expiration :

• Certificats EAP-TLS / PEAP : utilisés pour l'authentification 802.1X sur les points d'accès Wi-Fi et les switchs NAC. Durée typique : 1 an pour les certificats client, 2 ans pour les certificats serveur RADIUS.
• Certificats VPN (IKEv2, SSL-VPN) : expiration silencieuse sur le concentrateur ou sur les clients ; les connexions tombent à la prochaine rotation de session.
• Certificats SCEP / NDES : émis automatiquement par le MDM, mais la chaîne d'émission (AC racine, AC intermédiaire) peut expirer indépendamment des feuilles.

Certificats applicatifs et MDM

• Certificat APNs (Apple Push Notification service) : validité 1 an renouvelable. Son expiration rend le MDM incapable d'envoyer des commandes à tous les appareils Apple (iOS, iPadOS, macOS). Critique pour toute flotte mixte.
• Certificat d'identité MDM (Android Enterprise) : lié au DPC (Device Policy Controller) ; son expiration empêche l'inscription de nouveaux appareils et peut déclencher des alertes de conformité sur les appareils existants.
• Certificats TLS internes : serveurs d'applications, reverse proxies, portails d'authentification SSO. Une expiration sur un IdP (Identity Provider) bloque toutes les authentifications fédérées.

Certificats de signature de code et de configuration

• Profils de configuration signés (Apple, Windows) : un profil MDM dont le certificat de signature est expiré sera rejeté par le système lors du renouvellement ou de la réinscription.
• Certificats de signature de code (Developer ID, EV Code Signing) : impact sur les mises à jour d'agents de sécurité déployés en masse.

Architecture de surveillance : inventaire, monitoring et alertes

Inventaire centralisé des certificats

La première étape est de constituer un registre exhaustif. Sur une flotte hétérogène de 50 à 150 endpoints, quatre sources d'inventaire sont à consolider :

1. MDM (console centrale) : les MDM modernes exposent l'expiration des certificats poussés via profils. Intune retourne l'attribut certificateExpirationDateTime via Graph API ; Jamf Pro expose les certificats via l'endpoint /v1/mobile-devices/{id}/detail. FleetDM (open-source) collecte les certificats via l'extension osquery certificates table sur macOS et Windows.
2. Active Directory / ADCS (AD Certificate Services) : la commande certutil -view -out "NotAfter" -restrict "NotAfter<=NOW+30:00" liste les certificats expirant dans 30 jours.
3. Scan réseau TLS : des outils comme openssl s_client ou des scripts Nmap NSE (ssl-cert) permettent de sonder les ports 443, 8443, 636 (LDAPS), 993, 587 sur le réseau interne. À planifier hebdomadairement via CRON ou pipeline CI.
4. Apple Business Manager (ABM) : la console ABM affiche la date d'expiration du certificat APNs sous Réglages > Gestion des appareils. À surveiller manuellement faute d'API publique dédiée — intégrer une tâche calendrier 60 jours avant l'échéance.

Seuils d'alerte recommandés

Les CIS Benchmarks ne définissent pas de seuil universel, mais la pratique terrain converge vers trois niveaux :

• J-60 : alerte informationnelle (ticket basse priorité, assigné au responsable PKI ou DSI).
• J-30 : alerte moyenne (ticket P2, procédure de renouvellement déclenchée, validation RSSI si certificat critique).
• J-7 : alerte critique (ticket P1, escalade direction, communication aux utilisateurs si impact prévisible).

Pour le certificat APNs spécifiquement, anticipez à J-90 : le processus de renouvellement via Apple Business Manager nécessite le compte Apple ID original utilisé lors de la création — retrouver ce compte en urgence est une source fréquente de délais.

Intégration dans le pipeline d'alertes

L'inventaire statique ne suffit pas : les alertes doivent s'injecter dans les outils de ticketing et de notification existants. Trois intégrations à prioriser :

• Webhook vers ITSM (ServiceNow, Jira Service Management, Freshservice) : création automatique de ticket avec champ Expiry Date, Certificate CN, Concerned endpoints count.
• Canal Slack / Teams dédié #cert-expiry : notifications J-60/J-30/J-7, avec mention directe du responsable. Évite la noyade dans les alertes génériques.
• Dashboard SIEM (Splunk, Elastic SIEM, Microsoft Sentinel) : créer une règle de corrélation sur les événements Windows ID 4886 (demande de certificat) et ID 4887 (émission) pour tracer le cycle de vie et projeter les expirations futures.

Procédure de renouvellement : étapes et acteurs

Renouvellement d'un certificat EAP-TLS sur flotte Windows (ADCS + MDM)

1. DSI / ingénieur PKI — J-30 : Vérifier la validité de l'AC émettrice et du template de certificat dans la console ADCS (certsrv.msc). Si le template a été modifié, tester l'auto-enrôlement sur un poste pilote.
2. DSI — J-28 : Déclencher l'auto-renouvellement SCEP via le MDM (Intune : politique SCEP, paramètre Renewal threshold (%) à 20 % de la durée de vie pour un cert 1 an = renouvellement à J-73). Vérifier que le profil est bien ciblé sur tous les groupes d'appareils concernés.
3. RSSI — J-21 : Valider la conformité du nouveau certificat avec la politique PKI interne (longueur de clé ≥ 2048 bits RSA ou 256 bits EC, algorithme SHA-256 minimum, conformément aux recommandations NIST CSF PR.PT-3).
4. DSI — J-14 : Déployer le nouveau profil Wi-Fi sur 10 % de la flotte (groupe pilote). Vérifier la connectivité 802.1X sur les logs du contrôleur RADIUS (NPS sous Windows Server : Observateur d'événements, journal Security, ID 6272 / 6274).
5. DSI — J-7 : Déploiement full flotte via push MDM. Confirmer que 100 % des appareils gérés ont reçu le profil (rapport de conformité MDM).
6. DSI / RSSI — J+1 après expiration : Révoquer l'ancien certificat dans la CRL de l'AC interne. Archiver l'ancien certificat dans le registre PKI.

Renouvellement du certificat APNs (flotte Apple)

1. Identifier le compte Apple ID Apple School/Business Manager utilisé à l'émission originale (documenter ce compte dans le registre PKI dès la création).
2. Se connecter sur identity.apple.com/pushcert avec ce compte, télécharger le CSR depuis la console MDM, soumettre la demande de renouvellement — ne pas créer un nouveau certificat, le renouvellement conserve le même Topic (UID) et maintient la liaison avec les appareils inscrits.
3. Réimporter le certificat .pem dans la console MDM dans les 5 minutes suivant l'émission pour éviter toute interruption.
4. Vérifier dans le MDM que le statut APNs est Valid et que la date d'expiration est bien repoussée d'un an.

Implications nLPD et obligations de traçabilité

La nLPD (nouvelle Loi fédérale sur la protection des données), 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 personnelles (art. 8 nLPD). Un certificat TLS expiré sur un portail RH ou un serveur de messagerie constitue une mesure de sécurité défaillante : si une violation de données résulte de ce manquement, l'obligation de notification au PFPDT (Préposé fédéral à la protection des données et à la transparence) dans un délai de 72 heures s'applique (art. 24 nLPD).

La traçabilité du cycle de vie des certificats fait partie des preuves attendues lors d'un audit ISO 27001 (contrôle A.8.24 : utilisation de la cryptographie) ou d'un contrôle FINMA pour les établissements régulés. Maintenir un registre des certificats avec les dates d'émission, d'expiration, de renouvellement, et le responsable désigné n'est pas optionnel : c'est une exigence documentaire directement vérifiable.

En cas d'incident lié à un certificat expiré avec impact sur des données personnelles, le NCSC recommande de conserver les logs d'erreurs TLS et les événements d'authentification échoués comme éléments de preuve pour l'analyse post-incident.

Cas pratique : fiduciaire romande de 45 postes

Contexte : Fiduciaire basée à Sion, 45 postes Windows 11 (23H2) + 12 MacBook Pro sous macOS 14 Sonoma, 8 iPhones gérés via Apple Business Manager. Infrastructure : AD/ADCS interne, Wi-Fi 802.1X avec NPS, VPN IKEv2, Microsoft 365 avec MDM Intune. Aucun processus formalisé de surveillance des certificats avant l'audit interne Q1 2025.

Audit initial : L'inventaire réalisé via Intune Graph API + script PowerShell maison révèle :

• 3 certificats EAP-TLS client expirant dans moins de 45 jours sur des postes hors auto-enrôlement (machines achetées hors ABM, inscrites manuellement).
• Certificat APNs expirant dans 22 jours — aucune alerte reçue par l'équipe IT (1 personne).
• Certificat TLS du portail de déclaration TVA interne (IIS, port 443) expiré depuis 11 jours — connexions acceptées uniquement parce que les clients utilisaient un navigateur avec avertissement ignoré.

Chiffrage du risque :

• Expiration APNs : perte de gestion MDM sur 57 appareils Apple. Réinscription manuelle estimée à 45 min/appareil = 42,75 h × 120 CHF = 5 130 CHF.
• Portail TVA sans TLS valide : exposition à une interception potentielle de données comptables sensibles. Obligation de notification nLPD si données personnelles de clients transitent — risque réputationnel non chiffrable.

Procédure de remédiation mise en place (5 jours) :

1. Jour 1 — DSI (responsable IT) : Renouvellement APNs en urgence via identity.apple.com. Vérification immédiate du statut dans Intune (APNs valid, nouvelle expiration 15.05.2026).
2. Jour 1 — DSI : Renouvellement certificat TLS portail TVA via ADCS interne, déploiement sur IIS, test HTTPS avec openssl s_client -connect portail-tva.fiduciaire.local:443.
3. Jour 2 — DSI : Activation de l'auto-enrôlement SCEP dans Intune pour les 3 postes non conformes, ciblage via groupe AD dynamique CertExpirySoon.
4. Jour 3 — DSI + RSSI externe mandaté : Déploiement d'un script PowerShell planifié (tâche hebdomadaire) qui interroge ADCS et exporte un CSV cert-expiry-report.csv vers SharePoint. Seuils : colonnes avec mise en forme conditionnelle rouge/orange/vert.
5. Jour 4 — RSSI : Création dans Intune de deux alertes de conformité : certificat device expirant dans <30 jours → notification email DSI ; <7 jours → escalade dirigeant et ticket P1 Freshservice automatique via Logic App.
6. Jour 5 — DSI : Documentation du registre PKI (fichier Excel versionné sur SharePoint) : CN, émetteur, date émission, date expiration, responsable, procédure de renouvellement associée. Rappel calendrier Outlook pour chaque certificat à J-60.

Résultat : Zéro expiration non détectée sur les 8 mois suivants. Coût de mise en place : ~14 h de travail interne + 4 h de RSSI externe = environ 2 800 CHF. ROI immédiat comparé au scénario APNs évité (5 130 CHF).

Les outils de gestion de flotte comme SynGuard permettent de centraliser ces alertes multi-plateformes sans nécessiter plusieurs consoles distinctes — pertinent dès 20 appareils hétérogènes.

Récapitulatif opérationnel

1. Inventorier tous les certificats actifs : MDM (profils SCEP/PKCS), ADCS (certutil), scan TLS réseau, APNs ABM. Cible : registre exhaustif sous 5 jours ouvrables.
2. Définir trois seuils d'alerte — J-60 (info), J-30 (P2), J-7 (P1) — et les encoder dans le MDM et/ou le SIEM. Ne pas laisser les rappels sur des calendriers personnels.
3. Automatiser le renouvellement SCEP via MDM (Intune : Renewal threshold à 20 % ; Jamf : SCEP Payload avec renouvellement automatique activé) pour les certificats d'authentification device.
4. Documenter le compte Apple ID APNs dans le registre PKI dès la création, avec accès sécurisé partagé (gestionnaire de secrets, pas un compte perso d'employé).
5. Tester les alertes une fois par trimestre : modifier la date d'expiration d'un certificat de test dans le registre pour déclencher l'alerte J-7 et vérifier que le ticket et la notification arrivent bien.
6. Intégrer la revue PKI dans l'audit sécurité annuel : vérifier que l'AC racine interne, les AC intermédiaires et les certificats d'infrastructure (LDAPS, RDP, ADFS) sont couverts — pas seulement les certificats feuilles.
7. Documenter la procédure de renouvellement par type de certificat (runbook) : acteurs, commandes, délais, critères de validation. Indispensable si le responsable IT est absent lors d'une expiration critique.
8. Conserver les logs d'expiration et de renouvellement a minima 1 an pour répondre aux exigences de traçabilité nLPD / ISO 27001 A.8.24.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD, art. 8 (mesures techniques) et art. 24 (notification de violation).
• PFPDT — Préposé fédéral à la protection des données et à la transparence — Autorité de surveillance, procédures de notification et lignes directrices.
• NCSC — Centre national pour la cybersécurité — Recommandations pour les entreprises, gestion des incidents et signalement.
• CIS Benchmarks — Center for Internet Security — Référentiels de durcissement pour Windows, macOS, iOS et Android, incluant les bonnes pratiques PKI.
• NIST Cybersecurity Framework — nist.gov — Cadre de référence pour la gestion des risques, fonction Protect (PR.PT-3 : cryptographie).