Cloud PKI, SCEP ou PKCS avec Intune : choisir une architecture de certificats

Position recommandée

Je recommande Cloud PKI pour un parc Intune cloud-native lorsque ses limites, sa licence et la confiance des services consommateurs sont compatibles. Il supprime AD CS, NDES et le connecteur du chemin d’émission, tout en conservant un flux SCEP où la clé privée naît sur l’appareil.

Je conserve SCEP avec AD CS quand l’organisation doit intégrer une PKI Microsoft existante, garder ses autorités ou répondre à des consommateurs internes complexes tout en créant les clés sur les terminaux.

Je retiens PKCS lorsque la simplicité du connecteur et la compatibilité du scénario priment, après acceptation documentée du fait que la clé est créée et exportée dans l’infrastructure avant sa livraison protégée.

Je recommande Cloud PKI pour un parc Intune cloud-native lorsque ses limites, sa licence et la confiance des services consommateurs sont compatibles. Il supprime AD CS, NDES et le connecteur du chemin d’émission, tout en conservant un flux SCEP où la clé privée naît sur l’appareil.

Besoin, cas d’usage et périmètre de la recommandation

Cloud PKI fournit dans Intune des autorités racine et émettrices ou un modèle BYOCA, une RA SCEP, des CDP/AIA hébergés et des rapports. Le service remplace l’autorité locale, NDES et le Certificate Connector pour ce flux.

Le modèle Cloud PKI natif permet actuellement un nombre limité de CA par tenant. Les clés des CA licenciées sont protégées par Azure Managed HSM; une CA créée pendant un essai conserve son type de clé et ne peut pas être convertie ensuite, point à traiter avant le pilote.

SCEP avec AD CS crée la clé sur l’appareil et valide un challenge Intune via NDES. Il offre une intégration forte aux modèles et à la hiérarchie AD CS existante, au prix d’une publication HTTPS et d’une chaîne serveur à maintenir.

Critères de décision et options possibles

Pour Choisir entre Cloud PKI, SCEP et PKCS, je commence par trois résultats concrets: Inventorier sujets, EKU et SAN, Classer les exigences de clé et Comparer trois architectures. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Need → Key → Trust → Operate. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Inventorier sujets, EKU et SAN, Classer les exigences de clé et Comparer trois architectures. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Inventorier sujets, EKU et SAN, Classer les exigences de clé et Comparer trois architectures. Les responsabilités se répartissent ainsi: Need: Identité, usage, durée et assurance. Key: Lieu de création et protection privée. Trust: CA, chaîne, mapping et révocation. Operate: Supervision, support et rollback. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Cloud PKI non retenue », « SCEP trop fragile », « PKCS refusé sécurité » et « Deux chaînes non reconnues » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: une CA d’essai Cloud PKI ne change pas ensuite de type de clé, la limite de CA doit être revalidée, la migration de confiance précède l’émission et ne pas comparer uniquement l’installation initiale. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Cloud PKI fournit dans Intune des autorités racine et émettrices ou un modèle BYOCA, une RA SCEP, des CDP/AIA hébergés et des rapports. Le service remplace l’autorité locale, NDES et le Certificate Connector pour ce flux.

Le modèle Cloud PKI natif permet actuellement un nombre limité de CA par tenant. Les clés des CA licenciées sont protégées par Azure Managed HSM; une CA créée pendant un essai conserve son type de clé et ne peut pas être convertie ensuite, point à traiter avant le pilote.

SCEP avec AD CS crée la clé sur l’appareil et valide un challenge Intune via NDES. Il offre une intégration forte aux modèles et à la hiérarchie AD CS existante, au prix d’une publication HTTPS et d’une chaîne serveur à maintenir.

Prérequis, gouvernance et préparation

La préparation de Choisir entre Cloud PKI, SCEP et PKCS couvre inventaire des usages certificats, classification des clés et niveaux d’assurance, compatibilité des consommateurs, licences Cloud PKI vérifiées, cartographie AD CS/NDES/connecteurs. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Inventorier sujets, EKU et SAN. Classer les exigences de clé. Comparer trois architectures. Piloter le cas le plus exigeant. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• inventaire des usages certificats
• classification des clés et niveaux d’assurance
• compatibilité des consommateurs
• licences Cloud PKI vérifiées
• cartographie AD CS/NDES/connecteurs
• exigences de révocation et d’audit
• plan de coexistence et de sortie

Fonctionnement détaillé de Choisir entre Cloud PKI, SCEP et PKCS

Cloud PKI fournit dans Intune des autorités racine et émettrices ou un modèle BYOCA, une RA SCEP, des CDP/AIA hébergés et des rapports. Le service remplace l’autorité locale, NDES et le Certificate Connector pour ce flux.

Le modèle Cloud PKI natif permet actuellement un nombre limité de CA par tenant. Les clés des CA licenciées sont protégées par Azure Managed HSM; une CA créée pendant un essai conserve son type de clé et ne peut pas être convertie ensuite, point à traiter avant le pilote.

SCEP avec AD CS crée la clé sur l’appareil et valide un challenge Intune via NDES. Il offre une intégration forte aux modèles et à la hiérarchie AD CS existante, au prix d’une publication HTTPS et d’une chaîne serveur à maintenir.

• inventaire des usages certificats
• classification des clés et niveaux d’assurance
• compatibilité des consommateurs
• licences Cloud PKI vérifiées

Traitement, exploitation et cas limites de Choisir entre Cloud PKI, SCEP et PKCS

PKCS avec AD CS réduit la dépendance NDES mais exige que le connecteur puisse exporter temporairement la clé privée depuis le modèle. Je documente ce transfert, le durcissement du serveur et la différence avec une clé créée dans le TPM du poste.

La décision dépend du service consommateur: NPS, VPN, NAC, Wi-Fi, applications, appareils sans utilisateur, magasins requis, EKU, SAN, algorithmes, durée, disponibilité des CRL et support du strong mapping.

Je compare aussi le modèle d’exploitation: surveillance de CA et HSM, renouvellement des certificats RA/IIS, haute disponibilité, sauvegarde, séparation des rôles, révocation d’urgence, reporting et compétences disponibles 24 h/24.

• Tester chaîne et révocation
• Mesurer charge d’exploitation
• Décider avec GO/NO-GO

Lire les états propres à Choisir entre Cloud PKI, SCEP et PKCS

Une migration n’oblige pas à basculer toute la hiérarchie. Deux chaînes peuvent coexister pendant une période bornée si les serveurs consommateurs leur font confiance, si les sujets restent non ambigus et si la révocation est testée pour chacune.

Je mesure le coût total: licences, Windows Server, HSM, reverse proxy, sauvegardes, maintenance, astreinte et dette de migration. Une architecture moins chère à acquérir peut être plus coûteuse à opérer ou à auditer.

Le choix final est consigné dans une ADR avec hypothèses, exclusions, risques, preuve pilote, date de revue et stratégie de sortie. Je ne généralise pas tant qu’une perte de CA, de connecteur ou de réseau n’a pas été simulée.

• Cloud PKI non retenue — Matrice de compatibilité
• SCEP trop fragile — SLA et incidents
• PKCS refusé sécurité — Analyse de risque
• Deux chaînes non reconnues — NPS/VPN et chain build

Pilote et suivi opérationnel de Choisir entre Cloud PKI, SCEP et PKCS

Le pilote couvre le périmètre Cloud PKI, SCEP, PKCS, Intune et contrôle Inventorier sujets, EKU et SAN. Classer les exigences de clé. Comparer trois architectures. Les résultats sont segmentés selon les populations réellement concernées par Choisir entre Cloud PKI, SCEP et PKCS.

Les cas d’échec « Cloud PKI non retenue », « SCEP trop fragile », « PKCS refusé sécurité » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve une CA d’essai Cloud PKI ne change pas ensuite de type de clé, la limite de CA doit être revalidée, la migration de confiance précède l’émission, ne pas comparer uniquement l’installation initiale. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Choisir entre Cloud PKI, SCEP et PKCS se déploie par les étapes « Mesurer l’état de départ », « Configurer la population pilote », « Observer les indicateurs », « Décider la généralisation ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Inventorier sujets, EKU et SAN. Classer les exigences de clé. Comparer trois architectures. Piloter le cas le plus exigeant. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Need, Key, Trust, Operate doivent rester explicites lorsque la configuration est automatisée.

$ErrorActionPreference = 'Stop'
try {
  Get-ChildItem -Path Cert:\LocalMachine\My,Cert:\CurrentUser\My |
    Where-Object HasPrivateKey |
    Select-Object Subject,Issuer,Thumbprint,NotBefore,NotAfter,EnhancedKeyUsageList,PSParentPath
  certutil.exe -store -user My
  certutil.exe -store My
} catch { Write-Error "Inventaire des certificats impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Inventorier sujets, EKU et SAN, Classer les exigences de clé, Comparer trois architectures et Piloter le cas le plus exigeant. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Inventorier sujets, EKU et SAN.
• Classer les exigences de clé.
• Comparer trois architectures.
• Piloter le cas le plus exigeant.
• Tester chaîne et révocation
• Mesurer charge d’exploitation
• Décider avec GO/NO-GO

Exploitation, journaux et contrôle continu

La chronologie de Choisir entre Cloud PKI, SCEP et PKCS relie Need, Key, Trust, Operate. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Inventorier sujets, EKU et SAN. Classer les exigences de clé. Comparer trois architectures. Piloter le cas le plus exigeant. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Limite, licence ou confiance », « Publication ou dette NDES », « Transport de clé » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Inventorier sujets, EKU et SAN.
• Classer les exigences de clé.
• Comparer trois architectures.
• Piloter le cas le plus exigeant.
• Tester chaîne et révocation
• Mesurer charge d’exploitation
• Décider avec GO/NO-GO

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Choisir entre Cloud PKI, SCEP et PKCS apparaissent notamment sous la forme Cloud PKI non retenue, SCEP trop fragile, PKCS refusé sécurité, Deux chaînes non reconnues. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Choisir entre Cloud PKI, SCEP et PKCS crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Choisir entre Cloud PKI, SCEP et PKCS restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.