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.

Je commence par nommer le propriétaire de la décision, la population concernée et la preuve attendue. Cette étape paraît administrative, mais elle évite qu’un réglage technique soit utilisé pour compenser une responsabilité non définie entre identité, sécurité, support et gestion du poste.

La console cloud représente une intention et un état remonté. Je la compare toujours au résultat local, à l’identité réellement utilisée et à l’heure du dernier traitement. Une valeur verte, une affectation ou un HTTP 200 ne suffit pas à prouver tout le parcours.

Pour expliquer « Cloud PKI, SCEP et PKCS avec Intune », je commence par le besoin auquel la technologie répond, puis je sépare le plan de contrôle, le transport, les composants locaux, les états persistés et les données de résultat. Cette lecture évite d’attribuer au portail une décision prise par Windows ou à l’agent une limitation du service cloud.

Je distingue les interfaces supportées des détails internes observables. Les journaux, tâches et clés de registre aident à comprendre le fonctionnement, mais ils ne deviennent pas automatiquement des contrats stables sur lesquels bâtir une automatisation durable.

Enfin, je relie la théorie au cycle réel : déclenchement, traitement, résultat, nouvelle évaluation et comportement en cas de dérive. L’objectif est de comprendre ce qui se passe, pas seulement de reproduire une configuration.

Je qualifie la nature de chaque état : intention envoyée, valeur effective, inventaire, conformité, télémétrie ou simple cache d’affichage. Ces données n’ont ni la même fraîcheur ni la même autorité. Un résultat cohérent suppose de connaître qui produit l’information, à quel moment, dans quel contexte et selon quel mécanisme elle revient au service.

Je replace aussi la technologie dans son environnement. Les identités, certificats, licences, services réseau, versions clientes et autres outils de gestion peuvent modifier son comportement sans appartenir directement à son moteur. Cette frontière permet de distinguer une limitation intrinsèque d’une dépendance absente ou d’un conflit d’architecture.

Quand une observation terrain complète la documentation, je la présente comme un indice et non comme une garantie de support. Les noms de tâches, fichiers, événements ou rythmes internes peuvent changer. Je m’appuie sur eux pour expliquer et diagnostiquer, tandis que les décisions de conception reposent sur les interfaces et comportements officiellement documentés.

• À comprendre : comprendre l’architecture et ses limites
• À comprendre : mettre en œuvre un pilote observable
• À comprendre : construire une exploitation avec critères GO/NO-GO
• Périmètre étudié : Intune, Cloud PKI, SCEP
• Périmètre étudié : postes Windows et services Microsoft documentés
• Périmètre étudié : pilote représentatif avant généralisation

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

Je sépare les prérequis nécessaires à l’existence de la fonction de ceux qui ne concernent qu’un scénario d’administration. La présence d’une option dans une console ne prouve ni la prise en charge de la version cliente, ni l’éligibilité de la licence.

Les builds, éditions, rôles, dépendances réseau et contextes d’exécution doivent être confirmés avant d’interpréter un comportement. Les éléments internes observés mais non documentés comme interfaces publiques sont explicitement traités comme tels.

• 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

Cette séquence décrit ce que font les différents composants, depuis le déclenchement jusqu’au résultat. Elle sert de modèle mental : selon le scénario, certaines étapes peuvent être asynchrones ou exécutées dans un autre contexte.

Je distingue l’action demandée, son transport, son traitement local et son accusé de résultat. Cette distinction explique pourquoi deux écrans peuvent afficher temporairement des états différents sans qu’il y ait nécessairement une panne.

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.

Je mesure la couverture, le taux de succès, le délai de convergence, le nombre d’exceptions, les incidents et le temps de retour à l’état connu. Les seuils sont définis avant le pilote afin de ne pas les adapter après coup pour justifier une généralisation.

Les cas négatifs font partie de la recette : appareil hors ligne, identité non éligible, permission absente, version non supportée, conflit volontaire et rollback. Le système doit échouer de manière visible et sûre, sans exposer de secret ni créer une dérive silencieuse.

La généralisation suit des anneaux dont la composition reste stable pendant l’observation. Chaque vague dispose d’un propriétaire, d’une fenêtre, d’une consigne support et d’un point d’arrêt. Je n’ouvre la vague suivante qu’après la clôture des écarts de la précédente.

Interfaces d’observation, commandes et exemples

Les commandes illustrent les objets et états décrits dans l’article. Les exemples de diagnostic restent non testés, en niveau 1 et sans modification volontaire. Ils servent à comprendre les données disponibles, pas à industrialiser une collecte.

Une automatisation durable doit employer une API ou une interface officiellement supportée. Une clé de registre, un fichier ou une tâche interne peut évoluer avec Windows, l’agent ou le service.

# Exemple pédagogique non testé — niveau 1
$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

Le diagnostic de « Cloud PKI, SCEP et PKCS avec Intune » relie l’heure de la demande, l’identité, l’objet cloud, le poste et le résultat final. Je conserve les identifiants de corrélation utiles, mais je masque UPN, DeviceId, TenantId, noms internes, secrets, certificats privés et contenus métiers avant tout partage.

Je différencie absence de configuration, non-applicabilité, attente, erreur transitoire, refus d’autorisation et échec du composant local. Ces états n’appellent pas la même correction. Répéter une synchronisation ne transforme pas une politique non applicable en politique valide.

La collecte initiale reste en lecture seule. Une remédiation réelle doit être écrite au minimum au niveau 2, proposer une simulation, borner sa cible et restaurer l’état précédent. Pour une opération tenant-wide, privilégiée ou critique, les niveaux 3 ou 4 et une approbation formelle sont nécessaires.

• 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

Je vérifie le modèle sur un appareil représentatif en reliant la configuration du service, l’état reçu, le traitement local et la donnée remontée. L’objectif n’est pas de certifier la production, mais de confirmer que l’explication décrit bien le comportement observé.

Un cas d’usage est retenu lorsque la technologie répond au besoin sans ajouter une autorité concurrente, une dépendance non maîtrisée ou un niveau d’opacité incompatible avec l’exploitation.

• 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

Cette matrice relie les limites du modèle aux symptômes observables. Elle ne transforme pas une technologie en article de dépannage : elle montre où le fonctionnement normal peut diverger et quelles preuves permettent de comprendre cette divergence.

Une erreur isolée doit être replacée dans sa phase et son contexte. Je privilégie les résultats documentés du service et du client avant les détails d’implémentation susceptibles de changer.

Adoption progressive, réversibilité et vigilance

Pour introduire la technologie, je commence par un scénario borné, des appareils pilotes et des critères d’observation définis. L’adoption progresse uniquement si les dépendances, la supervision et les responsabilités de support sont comprises.

Le retour arrière dépend souvent de la propriété de la ressource et du cycle de synchronisation. Je le teste avant généralisation et je ne déduis jamais la réversibilité de la seule disparition d’un profil dans le portail.

• Réversibilité : retirer profil d’émission pilote
• Réversibilité : révoquer certificats pilotes si nécessaire
• Réversibilité : restaurer ancien profil et chaîne pendant transition
• Limite ou vigilance : ne jamais exporter une clé privée
• Limite ou vigilance : une CA est une infrastructure critique
• Limite ou vigilance : tester CRL côté relying party
• Limite ou vigilance : ne pas inclure de PII inutile dans Subject