Certificats PKCS avec Intune : fonctionnement, connecteur et cycle de vie

L’essentiel

Dans le modèle PKCS Intune avec Microsoft CA, le Certificate Connector traite une demande en attente, sollicite AD CS, exporte un PFX puis participe à sa livraison protégée au terminal. La clé n’est donc pas créée sur le terminal comme avec SCEP.

Le modèle AD CS doit autoriser l’export pendant le traitement du connecteur. Après installation sur Windows, la clé privée est marquée non exportable, mais la conception doit tout de même intégrer le passage temporaire de la clé par l’infrastructure.

Les exigences de strong certificate mapping de KB5014754 imposent de vérifier l’extension SID, la version du connecteur et tous les services consommateurs avant généralisation.

Dans le modèle PKCS Intune avec Microsoft CA, le Certificate Connector traite une demande en attente, sollicite AD CS, exporte un PFX puis participe à sa livraison protégée au terminal. La clé n’est donc pas créée sur le terminal comme avec SCEP.

Pourquoi cette technologie existe

Le profil Trusted certificate établit la chaîne de confiance. Le profil PKCS définit le type utilisateur ou appareil, le sujet, les SAN, les EKU, le fournisseur de stockage, la taille de clé, la durée et le seuil de renouvellement.

Intune place la demande dans le service. Une instance de Certificate Connector activée pour PKCS la récupère; lorsqu’il existe plusieurs connecteurs PKCS, chacun doit pouvoir joindre les autorités et disposer des mêmes permissions, car on ne fixe pas quel connecteur prendra une demande donnée.

Le compte du connecteur doit lire le modèle et enrôler auprès de l’autorité AD CS Enterprise. Le modèle doit être publié et permettre l’export de la clé pour que le connecteur constitue le PFX; un modèle Standalone CA n’est pas le scénario supporté par la documentation Intune.

Fonctionnement des certificats PKCS Intune s’appuie sur la chaîne Intune → Connector → AD CS → Endpoint. 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 AD CS Enterprise et modèle PKCS publié, Certificate Connector récent et enregistré, compte de service avec Read et Enroll, export de clé autorisé sur le modèle. 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 Demande jamais traitée, Denied by Policy Module et Certificat sans strong mapping. 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. Intune ouvre la séquence: Met en file la demande du profil PKCS. Connector prend ensuite le relais: Crée la demande et protège le PFX. Le traitement se poursuit avec AD CS, où Émet selon le modèle publié. Enfin, Endpoint ferme la boucle: Installe certificat et clé non exportable. 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. « Demande jamais traitée » conduit d’abord à vérifier État connecteur et logs, car la cause possible est Connecteur ou file PKCS. Pour « Denied by Policy Module », la preuve utile devient Trace connector et CA. Les cas « Certificat sans strong mapping » et « Clé inutilisable » 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 Fonctionnement des certificats PKCS Intune expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions AD CS Enterprise et modèle PKCS publié, Certificate Connector récent et enregistré, compte de service avec Read et Enroll, export de clé autorisé sur le modèle doivent être réunies en même temps. La validation porte ensuite sur Documenter sujet, SAN et EKU, Contrôler version et santé du connecteur, Valider modèle et permissions et Émettre au pilote. 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 profil Trusted certificate établit la chaîne de confiance. Le profil PKCS définit le type utilisateur ou appareil, le sujet, les SAN, les EKU, le fournisseur de stockage, la taille de clé, la durée et le seuil de renouvellement.

Intune place la demande dans le service. Une instance de Certificate Connector activée pour PKCS la récupère; lorsqu’il existe plusieurs connecteurs PKCS, chacun doit pouvoir joindre les autorités et disposer des mêmes permissions, car on ne fixe pas quel connecteur prendra une demande donnée.

Le compte du connecteur doit lire le modèle et enrôler auprès de l’autorité AD CS Enterprise. Le modèle doit être publié et permettre l’export de la clé pour que le connecteur constitue le PFX; un modèle Standalone CA n’est pas le scénario supporté par la documentation Intune.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose AD CS Enterprise et modèle PKCS publié, Certificate Connector récent et enregistré, compte de service avec Read et Enroll, export de clé autorisé sur le modèle, chaîne de confiance déployée. Ces conditions permettent de distinguer une limite de Fonctionnement des certificats PKCS Intune d’un scénario simplement non éligible.

• AD CS Enterprise et modèle PKCS publié
• Certificate Connector récent et enregistré
• compte de service avec Read et Enroll
• export de clé autorisé sur le modèle
• chaîne de confiance déployée
• stratégie strong mapping testée
• inventaire des services consommateurs

Cycle de fonctionnement, étape par étape

Le cycle de Fonctionnement des certificats PKCS Intune traverse Intune → Connector → AD CS → Endpoint. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans Fonctionnement des certificats PKCS Intune, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de Fonctionnement des certificats PKCS Intune

Le profil Trusted certificate établit la chaîne de confiance. Le profil PKCS définit le type utilisateur ou appareil, le sujet, les SAN, les EKU, le fournisseur de stockage, la taille de clé, la durée et le seuil de renouvellement.

Intune place la demande dans le service. Une instance de Certificate Connector activée pour PKCS la récupère; lorsqu’il existe plusieurs connecteurs PKCS, chacun doit pouvoir joindre les autorités et disposer des mêmes permissions, car on ne fixe pas quel connecteur prendra une demande donnée.

Le compte du connecteur doit lire le modèle et enrôler auprès de l’autorité AD CS Enterprise. Le modèle doit être publié et permettre l’export de la clé pour que le connecteur constitue le PFX; un modèle Standalone CA n’est pas le scénario supporté par la documentation Intune.

• AD CS Enterprise et modèle PKCS publié
• Certificate Connector récent et enregistré
• compte de service avec Read et Enroll
• export de clé autorisé sur le modèle

Traitement, exploitation et cas limites de Fonctionnement des certificats PKCS Intune

Le connecteur transmet ensuite le certificat et la clé par le parcours protégé du service. Intune livre le profil au terminal, qui installe le certificat dans le magasin utilisateur ou ordinateur correspondant au ciblage.

La propriété HasPrivateKey, le fournisseur cryptographique et les ACL de clé sont aussi importants que le certificat. Une application exécutée sous SYSTEM ne voit pas nécessairement CurrentUser\My, et une application utilisateur ne peut pas toujours utiliser LocalMachine\My.

La version moderne du Certificate Connector ajoute l’OID contenant le SID pour répondre au strong mapping lorsque l’utilisateur ou l’appareil est synchronisé depuis AD. La clé EnableSidSecurityExtension et la version minimale doivent être vérifiées selon la documentation actuelle.

• Vérifier magasin, clé et OID SID
• Tester Wi-Fi/VPN/NAC
• Tester renouvellement et révocation

Lire les états propres à Fonctionnement des certificats PKCS Intune

La taille 4096 bits est prise en charge sous Windows avec le Software KSP pour les profils PKCS, mais pas dans le TPM ni pour Windows Hello for Business. Je choisis l’algorithme selon le consommateur et les performances plutôt que d’augmenter mécaniquement la taille.

Renouvellement, révocation et suppression du profil ont des temporalités différentes. Je confirme que le connecteur possède les droits de révocation, que CRL et AIA sont accessibles et que le service cible ne conserve pas un cache d’autorisation obsolète.

Imported PFX constitue encore un autre flux: les certificats existent avant Intune et sont importés chiffrés. Je ne mélange pas ce modèle avec le PKCS émis à la demande par AD CS dans les procédures ou rapports.

• Demande jamais traitée — État connecteur et logs
• Denied by Policy Module — Trace connector et CA
• Certificat sans strong mapping — OID et version
• Clé inutilisable — HasPrivateKey et contexte

Pilote et suivi opérationnel de Fonctionnement des certificats PKCS Intune

Le pilote couvre le périmètre Intune, PKCS, PFX, Certificate Connector et contrôle Documenter sujet, SAN et EKU. Contrôler version et santé du connecteur. Valider modèle et permissions. Les résultats sont segmentés selon les populations réellement concernées par Fonctionnement des certificats PKCS Intune.

Les cas d’échec « Demande jamais traitée », « Denied by Policy Module », « Certificat sans strong mapping » 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 ne pas confondre PKCS et Imported PFX, tous les connecteurs PKCS doivent atteindre toutes les CA, protéger comptes et clés du connecteur, tester le strong mapping avant enforcement. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Documenter sujet, SAN et EKU. Contrôler version et santé du connecteur. Valider modèle et permissions. Émettre au pilote. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour Fonctionnement des certificats PKCS 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-ItemProperty 'HKLM:\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector' -ErrorAction SilentlyContinue
  Get-ChildItem Cert:\LocalMachine\My,Cert:\CurrentUser\My |
    Select-Object Subject,Thumbprint,NotAfter,HasPrivateKey,Extensions
} catch { Write-Error "Inventaire PKCS impossible : $($_.Exception.Message)"; exit 1 }

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

La chronologie de Fonctionnement des certificats PKCS Intune relie Intune, Connector, AD CS, Endpoint. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Documenter sujet, SAN et EKU. Contrôler version et santé du connecteur. Valider modèle et permissions. Émettre au pilote. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Connecteur ou file PKCS », « Modèle ou droits », « Version ou valeur registre » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Documenter sujet, SAN et EKU.
• Contrôler version et santé du connecteur.
• Valider modèle et permissions.
• Émettre au pilote.
• Vérifier magasin, clé et OID SID
• Tester Wi-Fi/VPN/NAC
• Tester renouvellement et révocation

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Documenter sujet, SAN et EKU, Contrôler version et santé du connecteur, Valider modèle et permissions et Émettre au pilote. Ces contrôles relient la configuration du service au résultat réellement observé.

• Documenter sujet, SAN et EKU.
• Contrôler version et santé du connecteur.
• Valider modèle et permissions.
• Émettre au pilote.
• Vérifier magasin, clé et OID SID
• Tester Wi-Fi/VPN/NAC
• Tester renouvellement et révocation

Limites, modes de panne et lecture des erreurs

Les écarts connus de Fonctionnement des certificats PKCS Intune incluent Demande jamais traitée, Denied by Policy Module, Certificat sans strong mapping, Clé inutilisable. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de Fonctionnement des certificats PKCS Intune commence sur le périmètre Intune, PKCS, PFX, Certificate Connector, Inside Endpoint — Intune, Connector, AD CS, Endpoint, AD CS Enterprise et modèle PKCS publié, Certificate Connector récent et enregistré, compte de service avec Read et Enroll. Les limites et actions de réversibilité ci-dessous cadrent la progression.