SCEP, ACME et certificats endpoints : guide PME suisse

Un certificat expiré sur un endpoint Windows ou macOS suffit à bloquer l'accès Wi-Fi 802.1X ou le VPN d'une PME entière. Voici comment industrialiser SCEP, ACME et le renouvellement sans intervention manuelle.

Un certificat oublié, un réseau coupé

Le lundi matin, 47 collaborateurs d'un bureau d'ingénierie vaudois n'arrivent plus à se connecter au Wi-Fi d'entreprise : le certificat client utilisé pour l'authentification EAP-TLS a expiré le dimanche à minuit. Aucune alerte n'avait été configurée. Le DSI passe quatre heures à ré-émettre manuellement les certificats via la console de l'autorité de certification interne, pendant que les équipes basculent sur des hotspots mobiles personnels — hors de tout périmètre de sécurité. Ce scénario se répète chaque trimestre dans des PME romandes qui gèrent leurs certificats à la main.

Pourquoi les certificats endpoints méritent une architecture dédiée

Les certificats X.509 sur les endpoints remplissent trois fonctions distinctes : authentification réseau (Wi-Fi 802.1X, VPN IPsec/TLS), chiffrement de flux (HTTPS interne, S/MIME) et signature de code ou de configuration (profils MDM, packages). Chaque fonction a ses propres durées de vie recommandées et ses propres acteurs dans la chaîne de délivrance.

Durées de vie et seuils d'alerte

Les certificats d'authentification client émis pour les endpoints ont typiquement une durée de validité de 1 an (365 jours) dans les PKI internes, parfois 2 ans pour les certificats machine. Les certificats TLS publics émis via ACME (Let's Encrypt ou ZeroSSL) ont une durée de 90 jours depuis 2024, avec des discussions actives pour descendre à 47 jours d'ici 2025 selon le CA/Browser Forum. Le seuil d'alerte opérationnel raisonnable est de 30 jours avant expiration pour les certificats internes, 15 jours pour les certificats ACME à renouvellement automatique — pour détecter un échec de renouvellement avant l'expiration effective.

PKI interne vs autorité publique : quand choisir quoi

Pour les PME de 20 à 150 endpoints, deux modèles coexistent :

PKI interne (ADCS / Microsoft CA, EJBCA, OpenXPKI) : indispensable pour les certificats d'authentification client (EAP-TLS, VPN) et les certificats machine joints à Active Directory. Les certificats sont émis par une CA racine interne dont le certificat est poussé via GPO ou profil MDM sur tous les endpoints.
CA publique via ACME : adapté aux services exposés (reverse proxies, portails intranets accessibles depuis Internet), aux endpoints qui hébergent un service HTTPS, et aux cas où la gestion d'une PKI interne dépasse la capacité opérationnelle de l'équipe IT.

Les deux modèles ne s'excluent pas : une PME peut très bien maintenir une CA interne pour l'authentification 802.1X et automatiser le renouvellement des certificats TLS de ses serveurs internes via NIST CSF-compatible ACME.

SCEP : délivrance automatisée pour les flottes MDM

SCEP (Simple Certificate Enrollment Protocol), défini dans le RFC 8894, est le protocole historique d'enrôlement de certificats pour les équipements réseau et les endpoints mobiles. Il est nativement supporté par Apple (iOS, macOS, iPadOS via ABM/ASM), Android Enterprise et Windows via Intune/NDES.

Architecture SCEP typique avec MDM

Dans un déploiement Intune + Apple Business Manager pour une PME de 60 endpoints macOS :

Le profil de configuration MDM inclut une charge utile SCEP payload pointant vers le serveur NDES (Network Device Enrollment Service) interne ou vers un connecteur cloud (Intune Certificate Connector).
Lors de l'enrôlement du Mac via ABM + Automated Device Enrollment, le profil est poussé automatiquement. Le Mac contacte le endpoint SCEP (typiquement https://ndes.example.ch/certsrv/mscep/mscep.dll sur le port TCP 443).
Le serveur NDES valide le challenge OTP ou le token Intune, contacte la CA interne (ADCS) et retourne le certificat signé au format PKCS#7 (CMS).
Le certificat est stocké dans le trousseau système macOS (System Keychain), non exportable si la configuration KeyIsExtractable = false est activée — recommandation CIS Benchmarks macOS niveau 1.
Le renouvellement est déclenché par le MDM avant expiration : Intune envoie une nouvelle demande SCEP automatiquement à J-30, sans intervention utilisateur.

Points de vigilance SCEP

Sécurisation du challenge SCEP : le challenge statique (mot de passe partagé) est à proscrire pour des flottes de plus de 10 endpoints. Utiliser les challenges dynamiques Intune ou une rotation automatique.
Disponibilité du NDES : si le serveur NDES est inaccessible (maintenance, panne), le renouvellement échoue silencieusement. Prévoir une supervision sur le port 443 avec alerte sous 15 minutes.
Android Enterprise : les endpoints Android gérés via Android Enterprise (Work Profile ou Fully Managed) supportent SCEP via les APIs KeyChain. La configuration passe par les profils MDM Android, identique au flux macOS.

ACME : renouvellement sans friction pour les services internes

Le protocole ACME (Automatic Certificate Management Environment), standardisé dans le RFC 8555, permet de renouveler des certificats TLS sans intervention humaine via des challenges de validation de domaine (HTTP-01, DNS-01, TLS-ALPN-01). Initialement conçu pour Let's Encrypt, ACME est aujourd'hui supporté par plusieurs CA commerciales et peut être déployé sur une PKI interne via des serveurs comme step-ca (Smallstep) ou Vault PKI (HashiCorp).

ACME en environnement interne (PKI privée)

Pour une PME qui ne veut pas exposer ses services sur Internet pour le challenge HTTP-01, le challenge DNS-01 est la bonne option : le client ACME (certbot, acme.sh, Caddy) crée un enregistrement DNS TXT _acme-challenge.monservice.example.ch via l'API du registrar ou du resolver interne, la CA valide, et le certificat est émis. Ce flux fonctionne entièrement hors Internet si la CA ACME est interne.

Pour les endpoints Windows 11 23H2 hébergeant un service HTTPS interne (par exemple un agent de monitoring ou un portail RH auto-hébergé), l'outil win-acme (anciennement LEWS) permet d'automatiser le cycle complet : demande initiale, stockage dans le magasin de certificats Windows (Local Machine > Personal), liaison IIS automatique, et renouvellement planifié via une tâche Windows Scheduler.

Durée de vie 90 jours : impact opérationnel

Avec des certificats ACME à 90 jours, le renouvellement doit être automatisé à J-30 au plus tard. Un renouvellement manuel dans une PME de 50 endpoints représente, si chaque certificat prend 10 minutes à traiter, potentiellement plusieurs heures de travail par trimestre — à multiplier par le nombre de services. L'automatisation n'est plus un confort, c'est une nécessité opérationnelle.

Renouvellement automatique : orchestration et supervision

Sources de vérité et inventaire

Avant d'automatiser, il faut inventorier. Les certificats peuvent se trouver à plusieurs endroits sur un endpoint :

macOS : trousseau système, trousseau login, profils de configuration MDM
Windows : certmgr.msc (utilisateur), certlm.msc (machine), magasin IIS, magasin JVM (cacerts) pour les applications Java
Linux/FleetDM : /etc/ssl/certs/, /etc/pki/, magasins applicatifs (Nginx, Apache, Postfix)

Les plateformes MDM (notamment via FleetDM pour les flottes Linux et macOS) permettent d'interroger les endpoints via des requêtes osquery pour lister les certificats et leurs dates d'expiration : SELECT subject, not_valid_after FROM certificates WHERE store = 'system';. Résultat exportable en CSV pour alimenter un tableau de bord de supervision.

Automatisation bout-en-bout

Un pipeline de renouvellement robuste pour une PME combine :

Inventaire continu : requête osquery ou script PowerShell planifié toutes les 24h, résultats centralisés.
Alertes à J-30 et J-15 : ticket automatique dans l'outil ITSM ou notification Teams/Slack avec le nom du endpoint, le sujet du certificat, et la date d'expiration.
Déclenchement du renouvellement : pour SCEP via MDM (automatique si le profil est correctement configuré), pour ACME via cron/systemd timer ou Windows Task Scheduler.
Validation post-renouvellement : vérification que le nouveau certificat est bien en place (test TLS avec openssl s_client ou équivalent PowerShell) et que la date de validité est correcte.
Alerte si échec : si le renouvellement SCEP ou ACME échoue à J-15, escalade automatique vers le DSI avec les logs d'erreur.

Considérations nLPD et traçabilité

Dans le contexte suisse, la nLPD (nouvelle Loi sur la protection des données) impose de protéger les données personnelles par des mesures techniques appropriées. Les certificats d'authentification client font partie de ces mesures : leur gestion lacunaire (certificats expirés, mauvaise révocation) peut constituer une faille de sécurité à déclarer au PFPDT (Préposé fédéral à la protection des données) si elle conduit à une violation de données. Tenir un registre des certificats émis, des dates de renouvellement et des révocations est une bonne pratique d'audit alignée ISO 27001 (contrôle A.8.24 dans la version 2022).

Cas pratique : fiduciaire romande, 35 endpoints Windows et macOS

Contexte : une fiduciaire à Sion (Valais) emploie 35 collaborateurs, dont 20 sur PC Windows 11 23H2 et 15 sur MacBook (macOS 14 Sonoma). Le parc est géré via Intune avec Apple Business Manager. L'accès Wi-Fi est authentifié par EAP-TLS sur un RADIUS Cisco ISE. Les collaborateurs accèdent également à un portail client HTTPS interne (IIS sur Windows Server 2022).

Problème initial : les certificats clients EAP-TLS avaient une durée de validité de 2 ans, émis manuellement via ADCS. En janvier 2024, 12 certificats arrivent à expiration simultanément (tous émis lors d'une migration groupée en janvier 2022). Le DSI passe 6 heures à ré-émettre et redéployer — à un coût interne estimé à CHF 900 (6h × CHF 150/h). Le portail HTTPS interne tourne, lui, avec un certificat auto-signé non reconnu par les navigateurs.

Architecture cible déployée en 3 mois :

Profil SCEP Intune pour les certificats EAP-TLS : durée ramenée à 1 an, renouvellement automatique déclenché à J-30 par Intune, challenge dynamique via Intune Certificate Connector. Coût de mise en place : environ 8h de travail DSI + 2h de test. Zéro renouvellement manuel depuis le déploiement.
Déploiement win-acme sur le serveur IIS : certificat TLS public (ZeroSSL via ACME, challenge DNS-01 via l'API du registrar Switch) pour le portail HTTPS interne. Renouvellement automatique tous les 90 jours via tâche planifiée. Le certificat est maintenant reconnu par tous les navigateurs sans exception.
Supervision via requête PowerShell planifiée : script exécuté chaque nuit, extrait tous les certificats machine avec Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) }, envoie un rapport par e-mail au DSI si des certificats approchent de l'expiration.
Registre des certificats : tableau SharePoint avec colonnes Subject, Emetteur, Date d'expiration, Système concerné, Responsable, Statut renouvellement. Mis à jour automatiquement par le script PowerShell.

Résultat mesuré après 12 mois : 0 interruption de service liée à un certificat expiré. Temps DSI consacré à la gestion des certificats : environ 30 minutes par trimestre (revue du tableau de bord), contre 6 à 8 heures auparavant. Économie annuelle estimée : CHF 2'700 en temps interne.

Un outil MDM comme SynGuard peut centraliser cet inventaire et déclencher les alertes directement depuis la console de gestion du parc, sans script ad hoc.

Récapitulatif opérationnel

Inventorier avant d'automatiser : lister tous les certificats présents sur les endpoints (osquery, PowerShell, certlm.msc) et identifier les magasins concernés (système, utilisateur, applicatif).
Choisir le bon protocole : SCEP pour les certificats d'authentification client déployés via MDM (EAP-TLS, VPN), ACME pour les certificats TLS de services internes et exposés.
Configurer le renouvellement automatique côté MDM : profil SCEP Intune avec renouvellement automatique à J-30, challenge dynamique, KeyIsExtractable = false sur macOS.
Passer à ACME pour les services HTTPS internes : win-acme (Windows), certbot ou acme.sh (Linux), challenge DNS-01 pour les environnements sans exposition Internet directe.
Mettre en place des alertes à J-30 et J-15 : supervision active avec escalade automatique si le renouvellement échoue, indépendamment de la plateforme MDM.
Tenir un registre des certificats : Subject, emetteur, date d'expiration, système, responsable — mise à jour automatisée, revue trimestrielle.
Réduire la durée de validité des certificats internes : passer de 2 ans à 1 an pour les certificats client, aligne sur les recommandations CIS Benchmarks et réduit la fenêtre d'exposition en cas de compromission.
Tester la révocation : vérifier que les CRL ou OCSP sont accessibles depuis les endpoints et que la révocation d'un certificat compromis est effective en moins de 15 minutes.
Documenter pour l'audit nLPD : le registre des certificats et les logs de renouvellement constituent des preuves de mesures techniques appropriées en cas de contrôle ou d'incident.
Signaler les incidents liés à des certificats compromis : en cas de violation de données résultant d'un certificat mal géré, consulter la procédure de signalement du NCSC (Centre national pour la cybersécurité).

Sources

nLPD — fedlex.admin.ch — Texte consolidé de la nouvelle Loi fédérale sur la protection des données, en vigueur depuis le 01.09.2023.
Procédure de signalement d'incidents — NCSC — Page officielle de signalement d'incidents de cybersécurité pour les entreprises suisses.
CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour macOS, Windows et Linux, incluant les recommandations sur la gestion des certificats.
NIST Cybersecurity Framework — nist.gov — Cadre de référence pour la gestion du risque cyber, incluant les contrôles de gestion des identités et des certificats.
PFPDT (Préposé fédéral à la protection des données et à la transparence) — Autorité suisse de contrôle de la protection des données, destinataire des notifications de violation selon la nLPD.

Gestion des certificats sur les endpoints : SCEP, ACME et renouvellement automatique