Certificats avec Intune : Cloud PKI, SCEP et PKCS de bout en bout

L’essentiel

Intune distribue les certificats de confiance puis demande un certificat utilisateur ou device via SCEP, PKCS ou imported PKCS. Chaque méthode place différemment la génération de clé et l’infrastructure d’émission.

Cloud PKI fournit des autorités root/issuing et une registration authority intégrée à Intune pour SCEP, avec CRL/AIA à rendre accessibles aux relying parties. BYOCA permet certains modèles de rattachement.

Le succès exige chaîne approuvée, EKU, Subject/SAN, clé privée, renouvellement et révocation. Le certificat doit ensuite réellement authentifier Wi-Fi, VPN ou ressource cible.

Intune distribue les certificats de confiance puis demande un certificat utilisateur ou device via SCEP, PKCS ou imported PKCS. Chaque méthode place différemment la génération de clé et l’infrastructure d’émission.

Pourquoi cette technologie existe

Le trusted certificate profile distribue uniquement la clé publique d’une CA. Il ne fournit pas de certificat client ni de clé privée. Root et issuing sont déployées dans les stores adaptés à chaque plateforme.

SCEP utilise une demande et génère normalement la clé sur le device. NDES/connector ou Cloud PKI RA valide la demande. PKCS s’appuie sur le PFX connector et un flux d’émission différent.

Cloud PKI crée des CA avec choix RSA et tailles supportées, publie AIA/CRL et expose un SCEP URI sur l’issuing CA. Seule une issuing CA Cloud PKI émet les certificats SCEP de ce modèle.

Cloud PKI, SCEP et PKCS avec Intune s’appuie sur la chaîne Trust → Identity → Enrollment → Relying party. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont cas d’usage et relying party, licence Cloud PKI si choisie, design CA et durée, root/issuing trust profiles. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Certificat absent, Chaîne non approuvée et Wi-Fi refuse. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Trust ouvre la séquence: Root et issuing CA distribuées. Identity prend ensuite le relais: Intune construit sujet et SAN. Le traitement se poursuit avec Enrollment, où SCEP/PKCS émet et livre. Enfin, Relying party ferme la boucle: Valide chaîne, EKU et révocation. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Certificat absent » conduit d’abord à vérifier Intune status et logs, car la cause possible est Profil ou connector/RA. Pour « Chaîne non approuvée », la preuve utile devient certutil verify. Les cas « Wi-Fi refuse » et « Révocation ignorée » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont Cloud PKI, SCEP et PKCS avec Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions cas d’usage et relying party, licence Cloud PKI si choisie, design CA et durée, root/issuing trust profiles doivent être réunies en même temps. La validation porte ensuite sur Valider architecture CA et rôles, Déployer root puis issuing trust, Créer profil SCEP/PKCS minimal et Contrôler Subject, SAN, EKU et store. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Le trusted certificate profile distribue uniquement la clé publique d’une CA. Il ne fournit pas de certificat client ni de clé privée. Root et issuing sont déployées dans les stores adaptés à chaque plateforme.

SCEP utilise une demande et génère normalement la clé sur le device. NDES/connector ou Cloud PKI RA valide la demande. PKCS s’appuie sur le PFX connector et un flux d’émission différent.

Cloud PKI crée des CA avec choix RSA et tailles supportées, publie AIA/CRL et expose un SCEP URI sur l’issuing CA. Seule une issuing CA Cloud PKI émet les certificats SCEP de ce modèle.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose cas d’usage et relying party, licence Cloud PKI si choisie, design CA et durée, root/issuing trust profiles, connecteurs sains si SCEP/PKCS on-prem. Ces conditions permettent de distinguer une limite de Cloud PKI, SCEP et PKCS avec Intune d’un scénario simplement non éligible.

• cas d’usage et relying party
• licence Cloud PKI si choisie
• design CA et durée
• root/issuing trust profiles
• connecteurs sains si SCEP/PKCS on-prem
• templates/EKU
• CRL/AIA accessibles

Cycle de fonctionnement, étape par étape

Le cycle de Cloud PKI, SCEP et PKCS avec Intune traverse Trust → Identity → Enrollment → Relying party. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Cloud PKI, SCEP et PKCS avec Intune, les étapes « Identifier les composants », « Suivre le flux », « Lire les états », « Valider le fonctionnement » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé et frontières de responsabilité

Le trusted certificate profile distribue uniquement la clé publique d’une CA. Il ne fournit pas de certificat client ni de clé privée. Root et issuing sont déployées dans les stores adaptés à chaque plateforme.

SCEP utilise une demande et génère normalement la clé sur le device. NDES/connector ou Cloud PKI RA valide la demande. PKCS s’appuie sur le PFX connector et un flux d’émission différent.

Cloud PKI crée des CA avec choix RSA et tailles supportées, publie AIA/CRL et expose un SCEP URI sur l’issuing CA. Seule une issuing CA Cloud PKI émet les certificats SCEP de ce modèle.

• cas d’usage et relying party
• licence Cloud PKI si choisie
• design CA et durée
• root/issuing trust profiles

Mise en œuvre, exploitation et cas limites

Le Subject et SAN doivent correspondre au protocole cible. UPN, DNS et URI sont des identités distinctes; je ne mets pas d’information personnelle non nécessaire.

Le renouvellement commence avant expiration selon le profil. Je teste le chevauchement ancien/nouveau et la réaction du Wi-Fi/VPN. La révocation dépend de la publication CRL et de son accessibilité.

Une relying party doit faire confiance à la chaîne et atteindre CRL/AIA. Installer la root sur le poste client ne suffit pas si le serveur RADIUS ignore la CA ou ne peut pas vérifier la révocation.

• Tester authentification réelle
• Tester renouvellement et révocation
• Documenter récupération/compromission CA

Méthode de validation à l’échelle du parc

Pour cloud pki, scep et pkcs avec intune, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Valider architecture CA et rôles. Déployer root puis issuing trust. Créer profil SCEP/PKCS minimal. Contrôler Subject, SAN, EKU et store. Elles sont définies avant le pilote de Cloud PKI, SCEP et PKCS avec Intune afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Certificat absent », « Chaîne non approuvée », « Wi-Fi refuse », « Révocation ignorée » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Cloud PKI, SCEP et PKCS avec Intune tient compte de ne jamais exporter une clé privée, une CA est une infrastructure critique, tester CRL côté relying party, ne pas inclure de PII inutile dans Subject. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Valider architecture CA et rôles. Déployer root puis issuing trust. Créer profil SCEP/PKCS minimal. Contrôler Subject, SAN, EKU et store. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Cloud PKI, SCEP et PKCS avec Intune, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

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

Observabilité : où lire l’état réel

La chronologie de Cloud PKI, SCEP et PKCS avec Intune relie Trust, Identity, Enrollment, Relying party. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Valider architecture CA et rôles. Déployer root puis issuing trust. Créer profil SCEP/PKCS minimal. Contrôler Subject, SAN, EKU et store. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Profil ou connector/RA », « Root/issuing manquante », « SAN/EKU/relying party », « CRL inaccessible » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Valider architecture CA et rôles.
• Déployer root puis issuing trust.
• Créer profil SCEP/PKCS minimal.
• Contrôler Subject, SAN, EKU et store.
• Tester authentification réelle
• Tester renouvellement et révocation
• Documenter récupération/compromission CA

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Valider architecture CA et rôles, Déployer root puis issuing trust, Créer profil SCEP/PKCS minimal et Contrôler Subject, SAN, EKU et store. Ces contrôles relient la configuration du service au résultat réellement observé.

• Valider architecture CA et rôles.
• Déployer root puis issuing trust.
• Créer profil SCEP/PKCS minimal.
• Contrôler Subject, SAN, EKU et store.
• Tester authentification réelle
• Tester renouvellement et révocation
• Documenter récupération/compromission CA

Limites, modes de panne et lecture des erreurs

Les écarts connus de Cloud PKI, SCEP et PKCS avec Intune incluent Certificat absent, Chaîne non approuvée, Wi-Fi refuse, Révocation ignorée. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Cloud PKI, SCEP et PKCS avec Intune commence sur le périmètre Intune, Cloud PKI, SCEP, Inside Endpoint — Trust, Identity, Enrollment, Relying party, cas d’usage et relying party, licence Cloud PKI si choisie, design CA et durée. Les limites et actions de réversibilité ci-dessous cadrent la progression.