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

Intro

Un lundi matin, 47 collaborateurs d'une PME vaudoise ne peuvent plus se connecter au réseau Wi-Fi d'entreprise : le certificat EAP-TLS déployé 13 mois plus tôt vient d'expirer simultanément sur tous les endpoints. Le helpdesk passe la journée à réinscrire manuellement les postes, pour un coût estimé à 6 500 CHF en temps IT. Ce scénario, reproductible, s'évite entièrement avec une chaîne de distribution de certificats pilotée par le MDM et un protocole de renouvellement automatique.

Pourquoi les certificats sur les endpoints sont un risque opérationnel

Les certificats machines servent à trois familles d'usages critiques : l'authentification réseau (802.1X EAP-TLS, VPN mutuel TLS), le chiffrement des communications internes (mTLS entre services, HTTPS interne), et la confiance dans les exécutables (signature de code, MDM enrollment). Chacun de ces usages a une durée de vie bornée.

La durée maximale des certificats TLS publics est désormais fixée à 398 jours par les navigateurs principaux (décision ballot SC-063 du CA/Browser Forum). Pour les certificats privés, la plupart des PKI internes émettent encore des certs machines à 1 ou 2 ans, ce qui crée des fenêtres de risque larges. L'industrie converge vers 90 jours (Let's Encrypt) voire 47 jours à horizon 2026 pour les certificats publics, un calendrier qui pousse à l'automatisation complète.

Sur un parc de 80 endpoints hétérogènes (macOS 14 Sonoma, Windows 11 23H2, iOS 17, Android 14), gérer manuellement les certificats machines revient à tenir un tableur avec 80+ lignes, des dates d'expiration dispersées, et zéro mécanisme d'alerte natif. La dérive est inévitable.

SCEP vs ACME : choisir le bon protocole selon l'infrastructure

SCEP — Simple Certificate Enrollment Protocol

SCEP (RFC 8894) est le protocole historique d'enrôlement de certificats pour les équipements réseau et les endpoints MDM. Il repose sur une transaction HTTP simple : le client génère une paire de clés, soumet une CSR (Certificate Signing Request) signée avec un mot de passe ou un challenge token, et reçoit le certificat signé par la CA. Le flux utilise le port TCP 443 (recommandé) ou TCP 80, avec des objets CMS (anciennement PKCS#7) encapsulés.

SCEP est nativement supporté par :

• Apple Business Manager + profils MDM (payload com.apple.security.scep) — iOS, iPadOS, macOS
• Windows Autopilot via Intune (NDES — Network Device Enrollment Service sur Windows Server)
• Android Enterprise via des profils MDM compatibles (payload Wi-Fi + certificat)
• FleetDM via la policy d'enrollment de certificats personnalisée

Limitation principale : SCEP ne gère pas nativement le renouvellement automatique. Le client doit re-soumettre une CSR avant expiration, ce qui nécessite soit une logique côté MDM (push d'un nouveau profil), soit un agent local. La plupart des MDM modernes intègrent un mécanisme de renouvellement déclenché X jours avant expiration (typiquement configurable entre 30 et 90 jours).

ACME — Automatic Certificate Management Environment

ACME (RFC 8555) est le protocole standardisé par l'IETF qui alimente Let's Encrypt. Il automatise l'ensemble du cycle de vie : émission, renouvellement, révocation. Le client ACME (Certbot, acme.sh, win-acme, ou l'agent intégré au MDM) dialogue avec le serveur ACME via HTTPS/443, prouve la possession du domaine ou de l'identité machine via des challenges (http-01, dns-01, tls-alpn-01, ou device-attest-01 pour les endpoints), puis reçoit le certificat.

ACME est particulièrement adapté aux scénarios suivants :

• Certificats serveurs internes avec une CA ACME privée (Step-CA, HashiCorp Vault PKI, Microsoft ADCS avec le module ACME)
• Endpoints macOS/Linux avec l'agent step-cli ou un équivalent
• Pipelines DevOps et workloads containerisés où le renouvellement doit être entièrement automatisé

Sur les endpoints Windows et mobiles gérés par MDM, SCEP reste plus universel car mieux pris en charge nativement dans les profils de configuration. ACME s'impose davantage côté serveurs et postes Linux. Les deux protocoles sont complémentaires : SCEP pour les endpoints MDM-managed, ACME pour les workloads autonomes.

Comparaison synthétique

• SCEP : déploiement via payload MDM, renouvellement piloté par le MDM, support universel Apple/Windows/Android. Requiert un serveur SCEP (NDES, EJBCA, ou service SaaS).
• ACME : renouvellement entièrement automatisé côté client, idéal pour les durées courtes (90 jours), nécessite un agent installé ou un runtime compatible. Standard ouvert, implémentations nombreuses.
• EST (Enrollment over Secure Transport, RFC 7030) : alternative à SCEP utilisée dans certains contextes IoT et télécom, moins répandu sur les endpoints classiques.

Architecture d'une PKI interne pour 20 à 150 endpoints

Composants minimaux

Une PKI opérationnelle pour une PME suisse de 50 endpoints comporte :

1. Root CA : hors ligne, clé RSA 4096 bits ou ECDSA P-384, durée 10 ans. Stockée sur un HSM ou a minima sur un volume chiffré hors réseau. N'émet jamais directement des certificats feuilles.
2. Intermediate CA (Issuing CA) : en ligne, émet les certificats machines et utilisateurs. Durée 3-5 ans. C'est elle qui publie les CRL (Certificate Revocation List) et le endpoint OCSP.
3. Serveur SCEP/ACME : frontal HTTP(S) que les endpoints contactent pour soumettre leurs CSR. Sur Windows Server, c'est le rôle NDES (AD CS). En mode SaaS ou open source, on trouve EJBCA Community, Step-CA (Smallstep), ou HashiCorp Vault PKI.
4. MDM : orchestre la distribution des profils de certificats et déclenche les renouvellements.

Distribution via les profils MDM

Sur macOS et iOS via Apple Business Manager — pardon, via les profils de configuration MDM signés distribués par ABM —, le payload SCEP spécifie l'URL du serveur, le challenge token, le Subject (CN, OU, O), les extensions (EKU : Client Authentication OID 1.3.6.1.5.5.7.3.2), et la durée de renouvellement. Le MDM pousse ce profil à l'enrollment, et re-pousse un nouveau profil avant expiration.

Sur Windows via Autopilot + Intune, le profil SCEP est configuré dans la section Devices > Configuration profiles > SCEP certificate. Les paramètres critiques : période de validité, période de renouvellement (en % ou en jours avant expiration), KSP (Key Storage Provider — recommandé : TPM si disponible), format du Subject. Le NIST SP 800-57 recommande ECDSA P-256 ou RSA 2048 bits minimum pour les certificats machines à durée courte.

Renouvellement : le point d'attention principal

Le renouvellement doit se déclencher assez tôt pour absorber les endpoints hors ligne (ordinateurs portables non connectés au réseau entreprise pendant plusieurs semaines). La règle pratique : déclencher le renouvellement à 80 % de la durée de vie du certificat. Pour un cert de 365 jours, cela donne 292 jours — soit 73 jours avant expiration. Pour un cert de 90 jours (scénario ACME), le renouvellement démarre à J+72, soit 18 jours avant expiration.

Pour les endpoints mobiles ou les laptops fréquemment hors site, prévoir une fenêtre de renouvellement d'au moins 30 jours, et monitorer dans le MDM les certificats dont l'expiration est dans moins de 21 jours sans renouvellement confirmé.

Révocation, OCSP et CRL : ne pas négliger la fin de vie

Un certificat révoqué sur un endpoint compromis (vol, départ d'un employé, malware détecté) doit être invalidé en temps réel. Deux mécanismes :

• CRL (Certificate Revocation List) : liste signée publiée par la CA, mise à jour périodiquement. Délai de propagation : typiquement 24h. Adapté aux PKI internes avec faible fréquence de révocation.
• OCSP (Online Certificate Status Protocol) : requête temps réel vers le répondeur OCSP de la CA (port TCP 80 conventionnellement). Réponse en millisecondes. Requis pour les scénarios où la révocation doit être quasi-immédiate (laptop volé avec accès VPN actif).

Dans le contexte nLPD (nouvelle Loi fédérale sur la protection des données, en vigueur depuis le 01.09.2023), la capacité à révoquer rapidement l'accès d'un endpoint compromis contenant des données personnelles est une mesure technique attendue dans le cadre de la sécurité par défaut (art. 8 nLPD). Documenter la procédure de révocation dans la politique de sécurité est une bonne pratique auditée lors des certifications ISO 27001.

Cas pratique

Contexte : fiduciaire vaudoise, 65 endpoints

Fiduciaire Dupraz & Associés SA, Lausanne. 65 endpoints : 40 postes Windows 11 23H2, 15 MacBook Pro macOS 14 Sonoma, 10 iPhones iOS 17 pour les associés. Réseau Wi-Fi d'entreprise en 802.1X EAP-TLS, VPN site-à-site avec authentification mutuelle TLS vers le datacenter hébergeant l'ERP fiscal. Aucun AD on-premise — infrastructure hybride Azure AD + Intune.

Problème initial

Les certificats machines Wi-Fi et VPN avaient été générés manuellement en mars 2023, durée 12 mois, sans mécanisme de renouvellement. En mars 2024, 58 endpoints sur 65 ont perdu simultanément l'accès réseau. La DSI a passé 3 jours à réinscrire les postes manuellement (réinscription SCEP manuelle, redéploiement des profils). Coût estimé : 8 400 CHF (2 techniciens × 3 jours × 700 CHF/jour × 2) + perte de productivité des collaborateurs bloqués.

Solution déployée

1. Mise en place d'un serveur NDES sur une VM Windows Server 2022 dans Azure (2 vCPU, 4 Go RAM, ~180 CHF/mois). Le NDES expose l'endpoint SCEP sur HTTPS/443, protégé par un certificat Let's Encrypt (renouvellement ACME automatique via win-acme).
2. Création d'une Issuing CA dans AD CS avec une Root CA hors ligne. Les certificats machines ont une durée de 180 jours (choix délibéré pour forcer la rotation semestrielle et réduire la surface d'exposition).
3. Profil SCEP Intune pour Windows : Subject = CN={{DeviceName}},OU=Fiduciaire,O=Dupraz,C=CH. EKU : Client Authentication. Renouvellement déclenché à 80 % (soit J+144, 36 jours avant expiration). KSP : TPM si disponible, sinon Software.
4. Profil SCEP MDM pour macOS et iOS : même paramétrage, poussé via le profil de configuration signé distribué par Intune. Le payload SCEP inclut le fingerprint SHA-256 du certificat NDES pour le pinning.
5. Monitoring : une règle Intune Compliance alerte la DSI si un endpoint présente un certificat expirant dans moins de 30 jours sans renouvellement confirmé. Seuil d'escalade : 21 jours.
6. Test de révocation : simulation du vol d'un MacBook — révocation du certificat dans AD CS, vérification du blocage Wi-Fi en moins de 15 minutes (délai OCSP configuré).

Résultat à 6 mois

Deux cycles de renouvellement automatique effectués sans intervention humaine. Zéro incident d'expiration. Coût mensuel du NDES : 180 CHF. ROI positif dès le deuxième mois par rapport au coût de l'incident de mars 2024.

Récapitulatif opérationnel

• Inventorier : lister tous les certificats machines en production (CN, CA émettrice, date d'expiration, usage : Wi-Fi, VPN, MDM enrollment, signature). Outil minimal : certutil -store My sur Windows, security find-certificate sur macOS.
• Choisir le protocole : SCEP pour les endpoints gérés par MDM (Windows Autopilot, Apple ABM, Android Enterprise) ; ACME pour les workloads Linux/serveurs autonomes. Ne pas mélanger sans documentation claire.
• Durée de vie : viser 180 jours maximum pour les certificats machines internes. Éviter les certs à 2 ans qui donnent une fausse impression de stabilité.
• Renouvellement à 80 % : configurer le déclenchement MDM à 80 % de la durée de vie. Pour 180 jours : renouvellement à J+144.
• Fenêtre hors-ligne : s'assurer que la fenêtre de renouvellement (durée restante au déclenchement) couvre au moins 30 jours pour les laptops nomades.
• OCSP ou CRL : activer OCSP sur l'Issuing CA pour permettre une révocation effective en moins de 15 minutes. Publier la CRL avec un délai ≤ 24h en fallback.
• Monitoring actif : alerter à J-30 et J-21 sur tout certificat non renouvelé. Intégrer dans le tableau de bord MDM ou SIEM.
• Documenter la révocation : procédure écrite (qui appelle qui, dans quel délai) pour les scénarios de vol ou de compromission d'un endpoint. Tester au moins une fois par an.
• Aligner sur les CIS Benchmarks : les benchmarks CIS pour Windows 11, macOS 14 et iOS incluent des contrôles sur la gestion des certificats (CIS Control 3 — Data Protection, et Control 12 — Network Infrastructure Management).
• Signaler les incidents PKI : en cas de compromission d'une CA ou de certificats utilisés pour de la signature malveillante, notifier le NCSC via le formulaire de signalement en ligne.

SynGuard accompagne les PME romandes dans la mise en place de ces architectures PKI intégrées à leur MDM existant, du design de la chaîne de confiance jusqu'au monitoring des expirations.

Sources

• Fedlex — Loi fédérale sur la protection des données (nLPD, RS 235.1) — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, notamment art. 8 sur les mesures techniques de sécurité.
• NCSC — Formulaire de signalement d'incidents cybernétiques — Procédure officielle de notification pour les entreprises suisses victimes d'incidents de sécurité.
• CIS Security — CIS Benchmarks — Référentiels de configuration sécurisée pour Windows, macOS, iOS et Android, incluant les contrôles sur la gestion des certificats.
• NIST SP 800-57 Part 1 Rev. 5 — Recommandations pour la gestion des clés cryptographiques — Lignes directrices sur les durées de vie et les algorithmes pour les certificats machines.
• ISO/IEC 27001 — Systèmes de management de la sécurité de l'information — Norme internationale de référence pour l'audit des politiques de gestion des certificats et de la PKI.