Certificats expirants : alertes proactives pour votre flotte

Un certificat TLS ou d'authentification qui expire silencieusement paralyse des services critiques en quelques secondes — sans avertissement préalable si le parc n'est pas instrumenté. Voici comment structurer une surveillance proactive sur une flotte mixte Windows, macOS et mobile.

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

Le 08.03.2023, une PME genevoise de services financiers a perdu l'accès à son VPN d'entreprise pendant 4h37 : cause racine, un certificat EAP-TLS utilisé pour l'authentification 802.1X avait expiré la nuit précédente. Aucune alerte n'avait été configurée. Le renouvellement manuel, coordonné entre le prestataire externe et le DSI interne, a mobilisé deux ingénieurs et généré un surcoût estimé à CHF 1'800 en heures non facturables. Ce scénario se répète chaque trimestre dans des dizaines de PME romandes dont la gestion de certificats reste artisanale.

La densification des flottes d'endpoints (postes Windows 11, MacBook sous macOS 14 Sonoma, iPhones en ABM, tablettes Android en Android Enterprise) multiplie les surfaces de rotation de certificats : TLS serveur, certificats client Wi-Fi, certificats de signature de code MDM, certificats SCEP émis par l'autorité interne, certificats push APNs Apple. Chacun a une durée de vie distincte, souvent comprise entre 90 jours (Let's Encrypt) et 3 ans (PKI interne), et un responsable différent.

Cartographier les certificats présents sur la flotte

Quatre familles à surveiller sur un parc mixte

Avant de poser des alertes, il faut un inventaire exhaustif. Sur une flotte de 50 à 150 endpoints typique d'une PME romande, on trouve systématiquement :

Certificats d'identité machine (SCEP/PKCS#12) — distribués via le profil MDM pour l'authentification Wi-Fi EAP-TLS ou VPN. Durée typique : 1 an. Renouvellement automatique possible via SCEP si l'autorité de certification le supporte.
Certificats APNs Apple — obligatoires pour tout MDM gérant des appareils iOS/macOS. Durée fixe : 365 jours. L'expiration coupe la capacité d'envoyer des commandes MDM à toute la flotte Apple simultanément.
Certificats TLS des services exposés — portail MDM, serveur de fichiers HTTPS interne, reverse proxy. Durée : 90 jours (Let's Encrypt avec renouvellement automatique via certbot/acme.sh) à 2 ans (DigiCert, COMODO).
Certificats de signature de profils MDM — signent les profils de configuration envoyés aux endpoints. Un profil signé avec un certificat expiré est rejeté par iOS 16+ et macOS 13+ sans message d'erreur explicite côté utilisateur.
Certificats Windows Hello for Business / TPM attestation — sur les postes déployés via Windows Autopilot en mode Hybrid Entra Join, des certificats d'attestation sont émis par les services Microsoft Entra. Durée : variable, généralement 1 an.

Méthodes d'inventaire selon la stack MDM

Sous Microsoft Intune, le rapport « Certificates » (Devices → Monitor → Certificates) liste tous les certificats SCEP et PKCS déployés via des profils de configuration, avec date d'expiration et état. L'export CSV est exploitable dans Excel ou Power BI. Pour les certificats non distribués par Intune (certificats racines poussés manuellement, certificats tiers), l'inventaire reste aveugle.

FleetDM (open source, compatible macOS, Windows, Linux) expose via son moteur osquery la table certificates qui retourne le CN, le serial, les dates not_valid_before et not_valid_after, et le keychain de stockage. Une requête de base :

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

Ce filtre retourne les certificats expirant dans les 30 prochains jours (2 592 000 secondes). FleetDM peut planifier cette requête toutes les 6h et déclencher une alerte webhook si le résultat n'est pas vide.

Sur Apple Business Manager (ABM) couplé à un MDM (Jamf, Mosyle, Kandji ou autre), le certificat APNs est visible dans Paramètres → Certificats push Apple MDM. La date d'expiration est affichée, mais aucune alerte native n'est envoyée avant expiration : c'est au DSI de la surveiller manuellement ou de la scripter.

Architecture d'alerte proactive : seuils et canaux

Définir les seuils d'alerte selon le type de certificat

Un seuil unique ne couvre pas la diversité des certificats. La pratique recommandée par le CIS Benchmarks pour la gestion des identités et des clés est d'adapter le délai d'alerte à la durée de vie totale du certificat :

Certificats 90 jours (Let's Encrypt) : alerte à J-30, rappel à J-14, critique à J-7.
Certificats 1 an : alerte à J-60, rappel à J-30, critique à J-14.
Certificats 2 à 3 ans (PKI interne, APNs) : alerte à J-90, rappel à J-45, critique à J-21.
Certificats Windows Autopilot / Entra : surveiller via le tableau de bord Entra ID → Devices → Device compliance, seuil à J-30.

Canaux de notification opérationnels

Les alertes email seules ont un taux de prise en compte insuffisant sur des équipes IT réduites (1 à 3 personnes dans une PME de 50 employés). Les canaux efficaces en pratique :

Webhook vers Microsoft Teams ou Slack — un message dans le canal #ops avec le CN du certificat, la date d'expiration et le responsable désigné. FleetDM et la plupart des MDM supportent les webhooks sortants nativement.
Ticket automatique dans le helpdesk (Freshservice, Zammad, Jira Service Management) — avec assignation au propriétaire du certificat et SLA de résolution de 5 jours ouvrés pour les alertes J-30.
Monitoring Prometheus/Grafana — l'exporter ssl_exporter (open source, github.com/ribbybibby/ssl_exporter) scrape les endpoints HTTPS et expose la métrique ssl_cert_not_after en timestamp Unix. Une règle Alertmanager envoie une alerte PagerDuty ou OpsGenie si (ssl_cert_not_after - time()) / 86400 < 30.

Gouvernance : propriétaire de chaque certificat

La surveillance technique est inutile sans propriétaire identifié. Pour chaque certificat inventorié, documenter dans le CMDB ou un simple tablier partagé : CN, SANs, autorité émettrice, date d'expiration, responsable (nom + email), procédure de renouvellement (automatique ACME, manuelle via CSR, via profil SCEP MDM), et délai de renouvellement estimé. En l'absence de CMDB, un fichier Markdown versionné dans Git suffit pour une équipe de 2-3 personnes.

Renouvellement automatisé : ce qui fonctionne sur une flotte MDM

SCEP et renouvellement proactif via MDM

Le protocole NIST-documenté SCEP (Simple Certificate Enrollment Protocol, RFC 8894) permet aux clients MDM de renouveler automatiquement leurs certificats d'identité avant expiration. Dans Intune, activer « Enable automatic renewal of SCEP certificate » avec un seuil de renouvellement à 20 % de la durée de vie restante — soit 73 jours sur un certificat d'1 an. Le client Windows contacte le NDES (Network Device Enrollment Service) ou le connecteur Intune Certificate Connector, génère une nouvelle CSR et récupère le certificat sans intervention humaine.

Sur macOS géré via ABM + MDM, le profil SCEP est poussé avec la clé KeyUsage (valeur 5 pour signature+chiffrement), SubjectAltName avec l'UPN de l'utilisateur, et Retries à 3. Si l'autorité de certification interne supporte le renouvellement automatique SCEP (Microsoft ADCS avec MSCEP, ou EJBCA), le certificat est renouvelé sans popup utilisateur.

Certificat APNs Apple : renouvellement non automatisable

Le certificat push APNs ne peut pas être renouvelé automatiquement — Apple exige une intervention manuelle sur le portail Apple Push Certificates Portal avec l'Apple ID institutionnel enregistré dans ABM. La procédure :

Générer une nouvelle CSR depuis la console MDM (30 secondes).
Se connecter sur identity.apple.com/pushcert avec l'Apple ID institutionnel.
Sélectionner « Renew » sur le certificat existant (ne pas en créer un nouveau, sinon tous les appareils se désenrôlent).
Uploader la CSR et télécharger le nouveau .pem.
Importer le .pem dans la console MDM.

Durée totale : 10 à 15 minutes si l'Apple ID et les accès sont disponibles. En cas d'expiration, la restauration nécessite de ré-enrôler manuellement chaque appareil iOS/macOS — sur 80 iPhones, cela représente plusieurs heures de travail terrain.

Intégration avec la nLPD et les obligations de sécurité

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 personnelles (art. 8 nLPD). Un certificat expiré sur un service traitant des données personnelles (portail RH, système CRM, messagerie) constitue un affaiblissement de la sécurité du transport des données — potentiellement qualifiable de violation de données si un tiers a pu intercepter du trafic non chiffré pendant la période d'expiration. En cas d'incident causé par un certificat expiré entraînant une fuite de données, le PFPDT (Préposé fédéral à la protection des données) doit être notifié dans les 72h si le risque pour les personnes concernées est vraisemblable.

Cas pratique : fiduciaire vaudoise, 65 endpoints

Contexte : Fiduciaire à Lausanne, 28 collaborateurs, 65 endpoints (40 postes Windows 11 23H2 en Autopilot Hybrid Entra Join, 15 MacBook Pro sous macOS 14.4, 10 iPhones 15 en ABM/iOS 17). Infrastructure : serveur ADCS interne, Intune comme MDM principal, Wi-Fi 802.1X avec EAP-TLS, VPN Always-On via certificats machine. Aucun outil de surveillance de certificats en place en janvier 2024.

Déclencheur : Le 14.02.2024, 40 postes Windows perdent l'accès au Wi-Fi entreprise simultanément. Cause : le certificat racine de l'ADCS interne, d'une durée de 5 ans, avait expiré. Les certificats machines fils émis par cette CA sont immédiatement invalides. Remise en service : 6h, mobilisant le DSI externalisé (CHF 2'400 de régie) plus une demi-journée de perturbation pour les comptables (impact estimé CHF 3'200 en productivité perdue).

Remédiation et outillage mis en place (procédure sur 3 semaines) :

Semaine 1 — Inventaire : déploiement de FleetDM en mode agentless (2h de setup). Requête osquery planifiée toutes les 6h sur la table certificates. Export initial : 127 certificats distincts sur la flotte, dont 11 avec une expiration dans les 90 jours.
Semaine 1 — Propriétaires : tablier Google Sheets partagé avec CN, date d'expiration, responsable, procédure. Rempli en 1h par le DSI externalisé.
Semaine 2 — Alertes : webhook FleetDM vers canal Teams #certificats. Seuils configurés : J-60 (info), J-30 (warning), J-14 (urgent). Ticket Freshservice auto-créé à J-30 avec assignation.
Semaine 2 — SCEP Intune : activation du renouvellement automatique SCEP à 20 % de vie restante sur les profils Wi-Fi et VPN. Test sur un groupe pilote de 5 postes : renouvellement automatique confirmé sans intervention.
Semaine 3 — APNs : calendrier annuel créé dans Outlook partagé, rappel 90 jours avant expiration APNs, propriétaire = DSI externalisé + Apple ID institutionnel documenté dans le gestionnaire de mots de passe (Bitwarden Teams).
Résultat à J+60 : 3 alertes J-30 reçues, 3 tickets créés, 3 renouvellements effectués sans incident. Coût total du projet : CHF 1'600 (setup FleetDM + configuration Intune + documentation). ROI positif dès le premier incident évité.

Récapitulatif opérationnel

Inventorier d'abord : requête osquery sur la table certificates (FleetDM) ou export Intune Certificates Monitor. Objectif : liste exhaustive avec CN, émetteur, expiration, pour 100 % de la flotte.
Documenter un propriétaire par certificat : nom, email, procédure de renouvellement, accès requis (Apple ID, accès ADCS, clé privée). Sans propriétaire, l'alerte reste sans effet.
Calibrer les seuils : J-30/J-14/J-7 pour les certs 90 jours ; J-60/J-30/J-14 pour les certs 1 an ; J-90/J-45/J-21 pour les certs 2-3 ans.
Automatiser les canaux : webhook Teams/Slack + ticket helpdesk. Ne pas compter sur l'email seul pour une équipe IT < 3 personnes.
Activer SCEP auto-renewal dans Intune pour tous les profils de certificats clients (Wi-Fi EAP-TLS, VPN). Seuil recommandé : 20 % de durée de vie restante.
Calendrier APNs : entrée récurrente annuelle avec rappel à J-90 et J-30, Apple ID institutionnel documenté et accessible (pas dans la boîte mail d'un collaborateur parti).
Tester les alertes : modifier temporairement un seuil à J+1 pour vérifier que le webhook et le ticket se déclenchent correctement. Ne pas présupposer que la chaîne fonctionne sans test.
Inclure la surveillance dans le scope nLPD : documenter la mesure dans le registre des activités de traitement comme contrôle technique de sécurité du transport. En cas d'audit PFPDT ou d'incident, la traçabilité est requise.
Revoir l'inventaire trimestriellement : chaque nouveau service déployé (reverse proxy, portail RH, API tier) génère un ou plusieurs nouveaux certificats. L'inventaire statique devient obsolète en quelques semaines.
Surveiller le certificat racine CA interne : souvent oublié car sa durée de vie est longue (5 à 10 ans). Son expiration invalide tous les certificats fils simultanément — l'impact est maximal. Alerte à J-365 minimum.

SynGuard intègre nativement ces contrôles de surveillance dans ses déploiements MDM pour flottes romandes, avec tableaux de bord d'expiration et escalades configurables selon la taille du parc.

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, art. 8 sur les mesures de sécurité techniques et organisationnelles.
Obligation de notification — PFPDT (edoeb.admin.ch) — Procédure de notification des violations de données au Préposé fédéral à la protection des données.
NCSC — Informations pour les entreprises — Conseils du Centre national pour la cybersécurité sur la gestion des risques techniques pour les PME suisses.
CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée incluant les recommandations de gestion des certificats et des clés pour Windows, macOS et systèmes mobiles.
NIST Publications — nist.gov — Publications de référence sur les protocoles cryptographiques, dont NIST SP 800-57 sur la gestion des clés et des certificats.

Surveillance des certificats expirants : alertes proactives pour la flotte