Guide pratique du magasin de certificats Windows — Faut-il l'installer côté utilisateur ou côté ordinateur ?

« Après le remplacement du poste pour la vérification en ligne des droits d’assurance maladie, on a réinstallé le certificat client sur le nouveau PC et on ne peut plus se connecter. » « Sur le poste de développement, ça se connecte bien à l’API bancaire, mais dès qu’on en fait un service Windows, on nous dit “certificat introuvable”. » « Et d’abord, entre le certificat visible dans certmgr.msc et celui visible dans certlm.msc, lequel est le bon ? » — quand on développe en sous-traitance des intégrations Web API avec certificat client, ce genre de demande revient régulièrement.

Vérification en ligne des droits d’assurance maladie dans les établissements de santé, démarches administratives électroniques, API bancaires, EDI avec des partenaires commerciaux : les certificats clients, autrefois réservés aux équipes infrastructure des grandes entreprises, sont désormais manipulés par les responsables informatiques et les développeurs d’applications métier des PME. Et les incidents liés aux certificats se ramènent en réalité à quelques schémas seulement. Se tromper d’emplacement, oublier les droits sur la clé privée, oublier l’échéance — ces trois-là.

Cet article s’adresse aux développeurs d’applications métier qui utilisent des certificats clients et aux responsables informatiques chargés du renouvellement des certificats. En prenant pour fil conducteur la décision « magasin utilisateur ou magasin ordinateur », il fait le tour de la structure des magasins de certificats Windows, de l’attribution des droits sur la clé privée, de l’inventaire des échéances avec PowerShell, et jusqu’au code d’utilisation depuis .NET. Le contenu s’appuie sur les sources primaires de Microsoft Learn à la date d’août 2026.

1. La conclusion, d’abord

• Le magasin de certificats Windows se décline en deux familles : « utilisateur » (CurrentUser) et « ordinateur » (LocalMachine). Le magasin utilisateur est propre à chaque compte (sous la clé de registre HKEY_CURRENT_USER), le magasin ordinateur est commun à tout le PC (sous HKEY_LOCAL_MACHINE).¹²
• Il existe aussi deux outils de gestion. certmgr.msc ouvre le magasin de l’utilisateur actuel, certlm.msc celui de l’ordinateur local. Depuis PowerShell, ce sont Cert:\CurrentUser et Cert:\LocalMachine.³⁴
• Le choix du magasin dépend de « sous quelle identité s’exécute le programme qui utilise ce certificat ». Pour une application interactive, c’est le magasin utilisateur ; pour une exécution sans surveillance (service Windows, IIS, Planificateur de tâches), c’est en principe le magasin ordinateur (tableau de décision du chapitre 3).
• La cause de « ça fonctionnait en développement mais on ne le trouve plus une fois transformé en service » est presque toujours unique. Un certificat qu’un développeur a placé dans son propre magasin utilisateur reste invisible depuis le CurrentUser d’un service qui s’exécute sous un autre compte (chapitre 3).
• Le certificat et la clé privée sont deux choses distinctes. Le simple fait de placer un certificat dans le magasin de l’ordinateur ne suffit généralement pas à permettre au compte de service de lire la clé privée. Accordez le droit de lecture au compte d’exécution via « Gérer les clés privées » dans certlm.msc.⁵
• Lors de l’importation d’un pfx, la clé privée est, par défaut, non exportable. Import-PfxCertificate importe la clé privée de façon à ce qu’elle ne puisse pas être réexportée, sauf si -Exportable est spécifié. Ce n’est pas un défaut : c’est la valeur par défaut souhaitable.⁶
• Les expirations se préviennent en automatisant l’inventaire. Une commande comme Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60 permet d’extraire mécaniquement les certificats qui expirent dans le nombre de jours indiqué.⁴
• Coder en dur l’empreinte numérique (thumbprint) dans le code ou la configuration condamne l’application à chaque renouvellement de certificat, car l’empreinte change forcément avec un nouveau certificat. Externaliser la configuration et prévoir une période de coexistence entre l’ancien et le nouveau certificat sont les bases de la conception (chapitres 5 et 7).

2. Vue d’ensemble du magasin de certificats — deux emplacements et des magasins logiques

2.1. Les deux familles : utilisateur et ordinateur

Le magasin de certificats Windows se divise globalement en deux « emplacements ».¹

• Magasin de certificats de l’ordinateur (ordinateur local, LocalMachine) : il n’y en a qu’un seul par PC, et il est commun à tous les utilisateurs et à tous les services de ce PC. Il réside physiquement sous la clé de registre HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates.²
• Magasin de certificats de l’utilisateur (utilisateur actuel, CurrentUser) : il est propre à chaque compte utilisateur. Il réside sous HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, c’est-à-dire qu’il fait partie du profil utilisateur.²

Il existe en outre un magasin propre à chaque compte de service³, qui réside dans une clé de registre par nom de service.² En pratique, ce sont d’abord ces deux premiers emplacements qu’il faut maîtriser.

Il y a une spécification importante à retenir. Chaque magasin logique du magasin utilisateur, à l’exception de « Personnel », affiche le contenu hérité du magasin de même nom dans le magasin ordinateur.¹ Par exemple, si vous placez le certificat d’une AC interne dans « Autorités de certification racines de confiance » du magasin ordinateur, ce certificat apparaît aussi dans le magasin « Autorités de certification racines de confiance » de tous les utilisateurs. À l’inverse, seul le magasin « Personnel » n’est pas hérité : c’est pourquoi, pour un certificat client (destiné au magasin personnel), c’est à vous de décider « qui doit pouvoir le voir ». Cette asymétrie est le fil rouge de tout cet article.

flowchart TB
    subgraph LM["Ordinateur (LocalMachine)<br/>Un par PC, commun à tous les utilisateurs et services"]
        LMMY["Personnel (My)"]
        LMROOT["Autorités de certification racines de confiance (Root)"]
        LMCA["Autorités de certification intermédiaires (CA)"]
        LMTP["Éditeurs de confiance (TrustedPublisher)"]
    end
    subgraph CU["Utilisateur (CurrentUser)<br/>Propre à chaque compte"]
        CUMY["Personnel (My)<br/>※non hérité = l'emplacement se choisit soi-même"]
        CUROOT["Autorités de certification racines de confiance (Root)"]
        CUCA["Autorités de certification intermédiaires (CA)"]
        CUTP["Éditeurs de confiance (TrustedPublisher)"]
    end
    LMROOT -.->|"contenu hérité et visible"| CUROOT
    LMCA -.->|"hérité"| CUCA
    LMTP -.->|"hérité"| CUTP

2.2. Les principaux magasins logiques

Chaque emplacement se subdivise en magasins logiques par rôle. Ce sont les dossiers visibles dans certmgr.msc / certlm.msc, et depuis PowerShell ou la ligne de commande, on utilise leurs noms internes en anglais.²⁴

2.3. Trois fenêtres sur le même magasin — certmgr.msc / certlm.msc / le lecteur Cert:

Il existe trois façons de consulter le même magasin.³⁴

• certmgr.msc : la console de gestion qui ouvre le magasin de l’utilisateur actuel.
• certlm.msc : la console de gestion qui ouvre le magasin de l’ordinateur local.
• Le lecteur Cert: de PowerShell : la hiérarchie Cert:\CurrentUser\... et Cert:\LocalMachine\... permet de manipuler les magasins comme un système de fichiers. Les certificats y sont identifiés par leur empreinte numérique.

Notez que si vous ajoutez manuellement le composant logiciel enfichable Certificats dans mmc.exe, vous choisissez la cible parmi trois types : « compte utilisateur », « compte d’ordinateur » et « compte de service ». Un utilisateur non administrateur ne peut gérer que le magasin de son propre compte utilisateur.³

Le premier pas d’une investigation consiste à faire coïncider « le magasin que consulte l’application » et « le magasin que vous consultez vous-même ». Étudier une panne de service en regardant certmgr.msc ne mènera jamais à la réponse, puisque vous ne regardez pas le même endroit.

3. Où placer le certificat — un tableau de décision fondé sur le mode d’exécution du programme

Le critère de décision est unique : sous quel compte s’exécute le programme qui utilise ce certificat ?

En cas de doute : ce qui s’exécute sans surveillance va dans le magasin ordinateur, ce qu’une personne manipule va dans le magasin utilisateur.

3.1. Anatomie de l’incident classique — « ça fonctionnait en développement mais on ne le trouve plus une fois transformé en service »

Cet incident se reproduit exactement selon la séquence suivante.

1. Le développeur importe le pfx en double-cliquant dessus sur son propre PC. Comme l’assistant a pour valeur par défaut « utilisateur actuel », le certificat se retrouve dans le magasin utilisateur du compte du développeur.
2. L’application en développement s’exécute depuis Visual Studio, donc sous le compte du développeur : en ouvrant StoreLocation.CurrentUser, le certificat est trouvé. Ça fonctionne.
3. L’application est enregistrée comme service Windows sur le serveur de production. Le service s’exécute sous NETWORK SERVICE ou un compte dédié.
4. Le CurrentUser que le code du service ouvre est le magasin utilisateur du compte d’exécution du service. Il est vide. « Certificat introuvable. »

flowchart TB
    subgraph DEV["Poste de développement"]
        D1["Importer le pfx par double-clic<br/>Valeur par défaut de l'assistant : « utilisateur actuel »"] --> D2["Se retrouve dans le magasin utilisateur<br/>du compte du développeur"]
        D2 --> D3["Exécuté depuis Visual Studio<br/>= s'exécute sous le compte du développeur"]
        D3 --> D4["Trouvé en ouvrant CurrentUser<br/>→ ça fonctionne"]
    end
    subgraph PROD["Serveur de production"]
        P1["Enregistré comme service Windows<br/>Compte d'exécution : NETWORK SERVICE, etc."] --> P2["Le CurrentUser ouvert par le code est<br/>le magasin utilisateur du compte de service"]
        P2 --> P3["Il est vide<br/>→ « Certificat introuvable »"]
    end
    D4 -.->|"Déploiement du même programme"| P1

Le point clé, c’est que le magasin utilisateur « existe en autant d’exemplaires que de comptes ». Même si l’administrateur ouvre certmgr.msc et constate « il est bien là, non ? », c’est son propre magasin qu’il vérifie, pas celui du compte de service. La solution n’est pas une copie improvisée : il faut réimporter le certificat dans le magasin de l’ordinateur et aligner le code sur StoreLocation.LocalMachine. Et cela va toujours de pair avec l’attribution des droits vue au chapitre suivant.

4. Clé privée et droits d’accès — le deuxième incident classique

4.1. Le certificat et la clé privée sont deux choses distinctes

Ce que vous voyez dans la liste du magasin de certificats, c’est le certificat (une information publique), pas la clé privée elle-même. Or, ce dont l’authentification client a réellement besoin, c’est de l’opération de signature effectuée avec la clé privée : « le voir dans la liste » et « pouvoir l’utiliser » sont donc deux problèmes distincts. Confondre les deux produit des pannes difficiles à diagnostiquer au premier coup d’œil : « le certificat est là mais la négociation TLS échoue », ou des erreurs internes du type Access Denied.

4.2. La pratique de l’importation d’un pfx — l’exportabilité est un choix de conception

La paire certificat + clé privée se transmet sous forme de fichier pfx (PKCS #12), qui peut être importé dans le magasin avec Import-PfxCertificate.⁶

$pwd = Get-Credential -UserName '(saisissez le mot de passe ci-dessous)' -Message 'Mot de passe du PFX'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

Le point important ici, c’est le comportement par défaut : à moins d’ajouter -Exportable, la clé privée importée ne peut pas être réexportée.⁶ Importer systématiquement en mode exportable « au cas où il faudrait migrer plus tard » revient à ajouter une voie de fuite supplémentaire pour la clé privée. Conservez le pfx d’origine dans un stockage sécurisé, et gardez comme règle de base que la clé privée dans le magasin doit rester non exportable — c’est ce que nous recommandons. Notez d’ailleurs que c’est précisément la conservation du pfx d’origine et de son mot de passe qui finit souvent laissée en clair et sans protection. Nous avons détaillé cette approche dans « Stockage des informations sensibles d’une application Windows — éviter les configurations en clair avec DPAPI » et « La gestion sécurisée des identifiants avec PowerShell ».

4.3. Attribuer les droits sur la clé privée au compte de service

La clé privée d’un certificat placé dans le magasin de l’ordinateur est généralement configurée, par défaut, pour n’être lisible que par les administrateurs et SYSTEM. Un service qui s’exécute sous LocalSystem peut donc lire la clé privée sans configuration supplémentaire, mais pour toute autre exécution — NETWORK SERVICE, compte de service dédié, identité de pool d’applications IIS, etc. — il faut accorder explicitement le droit de lecture au compte d’exécution. La procédure passe par l’interface du composant enfichable Certificats.⁵

1. Ouvrez certlm.msc (ou le composant enfichable Certificats ciblant le compte d’ordinateur).
2. Dans « Personnel » → « Certificats », faites un clic droit sur le certificat concerné et ouvrez « Gérer les clés privées » depuis « Toutes les tâches ».
3. Dans l’onglet « Sécurité », ajoutez le compte d’exécution (NETWORK SERVICE, compte de service dédié, identité de pool d’applications IIS, etc.) et autorisez « Lecture ».⁵

Le contrôle total n’est pas nécessaire : le droit de lecture suffit pour un usage limité à la signature. À l’inverse, accorder le contrôle total à Everyone parce que « ça ne fonctionne pas » revient à traiter la clé privée comme un mot de passe en clair, et doit absolument être évité. Le placement dans le magasin de l’ordinateur et l’attribution des droits sur la clé privée vont toujours de pair : il suffit d’inscrire cela dans la procédure pour éliminer ce type d’incident.

5. Prévenir les incidents d’expiration — inventaire, remplacement et registre

5.1. Faire l’inventaire avec PowerShell

La date d’expiration d’un certificat se trouve dans la propriété NotAfter. L’inventaire peut se faire mécaniquement avec Get-ChildItem sur le lecteur Cert:.⁴

# Lister le magasin « Personnel » de l'ordinateur trié par date d'expiration
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# Extraire uniquement ceux qui expirent dans 60 jours (0 pour les déjà expirés)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays est un paramètre qui renvoie les certificats qui expirent dans le nombre de jours indiqué ; avec 0, ce sont les certificats déjà expirés qui apparaissent.⁴ En faisant de cette commande une tâche planifiée mensuelle qui parcourt tous les serveurs et en centralisant le résultat par e-mail ou dans un registre, on évite quasiment tous les incidents du type « la vérification des droits ne passe plus dès le lundi matin à cause d’un certificat expiré ».

5.2. La procédure de remplacement — la période de coexistence et le piège de l’empreinte

Le renouvellement d’un certificat ne consiste pas à « supprimer puis installer », mais à « ajouter, puis basculer, puis vérifier, puis seulement alors supprimer ».

1. Importez le nouveau certificat (pfx) dans le même magasin. Comme les empreintes diffèrent, l’ancien et le nouveau peuvent coexister dans le même magasin.
2. Attribuez les droits sur la clé privée du nouveau certificat (chapitre 4). C’est le point qu’on oublie le plus facilement lors d’un renouvellement. Les droits s’attachent à la clé privée de chaque certificat : remplacer le certificat implique de refaire l’attribution.
3. Faites d’abord la déclaration auprès du système partenaire (pour les API nécessitant un enregistrement préalable du certificat), tout en continuant à opérer avec l’ancien certificat, afin de ménager une période de coexistence pendant laquelle les deux sont acceptés. Basculer d’abord ferait rejeter le nouveau certificat par le partenaire et interromprait la communication en production.
4. Basculez la configuration de l’application vers le nouveau certificat et vérifiez le fonctionnement.
5. Après une période suffisante, supprimez l’ancien certificat.

flowchart LR
    I["1. Importer le nouveau pfx<br/>dans le même magasin (coexistence)"] --> P["2. Attribuer les droits sur<br/>la clé privée du nouveau certificat"]
    P --> R["3. Enregistrement préalable<br/>auprès du partenaire (ancien certificat toujours actif)"]
    R --> SW["4. Réécrire l'empreinte en configuration<br/>et basculer, puis vérifier"]
    SW --> DEL["5. Supprimer l'ancien certificat<br/>après la période de coexistence"]

Le plus grand piège, ici, est l’empreinte inscrite dans les fichiers de configuration ou le code. Comme l’empreinte est unique à chaque certificat, elle change forcément à chaque renouvellement. S’il reste ne serait-ce qu’un seul endroit qui référence l’ancienne empreinte, on obtient « le certificat est renouvelé mais on ne peut plus se connecter ». La méthode fiable consiste à gérer dans un registre tous les endroits où l’empreinte est inscrite (configuration de l’application, liaison IIS, scripts, déclaration au partenaire).

5.3. Pour un registre des certificats

Un simple fichier Excel suffit amplement pour commencer. Créez au minimum les colonnes suivantes — usage, émetteur, sujet, empreinte, emplacement (nom du serveur + magasin), compte détenant les droits sur la clé privée, date d’expiration, lien vers la procédure de renouvellement, responsable — et croisez-les avec le résultat de l’inventaire du paragraphe 5.1. La réalité des incidents liés aux certificats n’est pas un problème technique, mais celui de « personne n’en tient la liste » : c’est pourquoi un registre est l’outil le plus efficace.

6. Vérification et diagnostic des échecs — la chaîne et la distribution de la racine

6.1. Les bases de la vérification de chaîne, et certutil

Les erreurs du type « ce certificat n’est pas approuvé » signalent que la chaîne (le chemin de certification) entre le certificat final et l’AC racine est rompue quelque part. certutil est pratique pour cette investigation.⁷

flowchart TB
    LEAF["Certificat final<br/>(certificat client, certificat serveur)"] --> INT["Certificat d'AC intermédiaire<br/>Emplacement : magasin des autorités intermédiaires (CA)"]
    INT --> ROOT["Certificat d'AC racine<br/>Emplacement : autorités racines de confiance (Root)"]
    INT -.->|"Introuvable<br/>(ni présenté, ni via AIA, ni dans le magasin)"| E1["Impossible de construire la chaîne<br/>(cause classique n°1)"]
    ROOT -.->|"Non distribuée"| E2["Erreur « non approuvé »<br/>(cause classique n°2)"]
    LEAF -.->|"Expiré"| E3["Erreur de période de validité<br/>(cause classique n°3)"]

:: Construire et vérifier la chaîne du fichier de certificat (avec récupération de l'URL de révocation)
certutil -urlfetch -verify client.cer

:: Si l'application cible utilise le magasin utilisateur, ajouter -user pour vérifier dans le même contexte
certutil -user -urlfetch -verify client.cer

:: Extraire le contenu du magasin (-user pour le magasin utilisateur)
certutil -store My
certutil -user -store My

certutil -verify vérifie le certificat, la CRL et la chaîne ; sans spécifier de CACertFile, il construit et vérifie la chaîne complète.⁷ La sortie est longue, mais elle permet de repérer à quel niveau la confiance est rompue et si l’information de révocation a pu être obtenue. Les causes typiques sont au nombre de trois : (1) le certificat d’AC intermédiaire est introuvable (le correspondant TLS ne l’a pas envoyé, il n’est pas récupérable via l’information AIA du certificat, et il n’est pas non plus présent dans le magasin « Autorités de certification intermédiaires ») ; (2) la racine de l’AC interne n’est pas distribuée dans « Autorités de certification racines de confiance » ; (3) le certificat lui-même est expiré. Comme l’AC intermédiaire peut aussi être résolue par la présentation du correspondant ou la récupération automatique via AIA, considérez son placement dans le magasin comme « l’un des moyens de fiabiliser », et non le seul.

6.2. Distribuer la racine d’une AC interne ou d’un certificat auto-signé via GPO/Intune

Si vous utilisez une AC interne ou un certificat auto-signé de test, il faut distribuer ce certificat racine à chaque PC. Plutôt que de l’installer manuellement poste par poste, appuyez-vous sur un mécanisme de distribution.

• Environnement Active Directory (GPO) : importer le certificat dans « Autorités de certification racines de confiance », sous Configuration ordinateur\Stratégies\Paramètres Windows\Paramètres de sécurité\Stratégies de clé publique de la stratégie de groupe, le distribue aux PC concernés.⁸
• Environnement géré par Intune : le profil « Certificat de confiance » distribue les certificats d’AC racine ou intermédiaire. Sous Windows, vous pouvez choisir le magasin de destination (racine ou intermédiaire de l’ordinateur, intermédiaire de l’utilisateur).⁹

Comme indiqué en 2.1, placer un certificat dans la racine du magasin ordinateur le rend approuvé par tous les utilisateurs.¹ C’est précisément pour cela qu’il faut regarder en face le risque inverse : placer un certificat auto-signé dans « Autorités de certification racines de confiance » revient à implanter un nouveau point d’ancrage de confiance sur ce PC. Si sa clé privée fuit, cela devient un tremplin pour émettre des certificats usurpant n’importe quel site ou logiciel. Pour un usage permanent, la bonne pratique est de monter une AC interne dont la clé privée est correctement protégée, ou de se rapprocher d’un certificat d’une AC publique ; le principe pour une racine auto-signée reste « réservée aux environnements de test, avec une durée de validité limitée ».

7. Le point de vue du développeur — bien utiliser le magasin depuis .NET

7.1. Rechercher par empreinte avec X509Store

Depuis .NET, on ouvre le magasin avec X509Store et on récupère le certificat avec Find.¹⁰¹¹

using System.Security.Cryptography.X509Certificates;

static X509Certificate2 GetClientCertificate(string thumbprint)
{
    using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
    store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);

    var found = store.Certificates.Find(
        X509FindType.FindByThumbprint, thumbprint, validOnly: true);

    if (found.Count == 0)
        throw new InvalidOperationException(
            $"Certificat introuvable : empreinte={thumbprint}, " +
            $"emplacement={store.Location}\\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"Certificat trouvé, mais sans clé privée associée (par exemple importé " +
            $"depuis un .cer) : empreinte={thumbprint}, emplacement={store.Location}\\{store.Name}");

    return cert;
}

La décision du chapitre 3 se répercute directement ici : StoreLocation.LocalMachine pour du code exécuté par un service, StoreLocation.CurrentUser pour une application interactive. Autre point d’attention : le troisième argument de Find, validOnly. true ne renvoie que les certificats valides ayant passé la vérification.¹¹ C’est une garantie contre la capture accidentelle d’un certificat expiré, mais un certificat auto-signé de test dont la chaîne n’est pas approuvée tombe lui aussi du côté « introuvable » : quand un certificat est présent mais « introuvable », pensez aussi à ce point. Enfin, le message d’erreur affiché en cas d’échec doit toujours préciser, comme dans l’exemple ci-dessus, quel magasin a été recherché. Cela change d’un ordre de grandeur le temps d’investigation de l’incident du chapitre 3.

7.2. Charger un certificat client dans HttpClient

Le certificat récupéré est présenté au serveur en l’ajoutant à HttpClientHandler.ClientCertificates. Cette collection est l’ensemble des certificats présentés au serveur pour l’authentification client par certificat.¹²

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(GetClientCertificate(thumbprint));

var client = new HttpClient(handler);
// À partir d'ici, on l'utilise comme un HttpClient classique

Notez que, pour les versions .NET Core, la documentation précise que si le certificat possède l’attribut d’usage de clé (Key Usage), il ne sera utilisé pour l’envoi de la requête que s’il inclut « Digital Signature ».¹² Si vous êtes amené à demander l’émission d’un certificat client, veillez à bien communiquer son usage (authentification client). Par ailleurs, un mauvais schéma de création de HttpClient peut provoquer un épuisement des sockets ou des problèmes de suivi DNS ; la conception à durée de vie longue, au niveau du handler, est celle décrite dans « Pourquoi il ne faut pas envelopper HttpClient dans un using ».

7.3. Le problème de l’empreinte codée en dur qui casse au renouvellement

La recherche par empreinte est fiable, mais intégrer l’empreinte dans le code impose une compilation et une publication à chaque renouvellement de certificat. La réponse en conception se décline en trois niveaux.

• Le minimum : externaliser l’empreinte dans un fichier de configuration (appsettings, etc.) pour pouvoir la remplacer sans publication. Consigner l’emplacement de cette configuration dans le registre du paragraphe 5.3.
• Aller plus loin : rechercher par nom de sujet ou par émetteur, combiné avec validOnly: true, pour sélectionner « parmi les certificats actuellement valides portant ce nom, celui dont le NotAfter est le plus lointain ». On bascule alors automatiquement vers le nouveau certificat pendant la période de coexistence. Cela comporte toutefois un risque de capturer par erreur un certificat homonyme non voulu : associez toujours une vérification de l’émetteur et une journalisation. Cette bascule automatique ne fonctionne d’ailleurs que si le partenaire n’exige pas d’enregistrement préalable du certificat. Pour les API qui l’exigent (paragraphe 5.2), le risque est de basculer sans le vouloir vers un certificat simplement importé mais non encore enregistré, ce qui interromprait la communication : dans ce cas, restez sur une externalisation en configuration, en ne basculant qu’après avoir confirmé l’enregistrement.
• Verrouiller par l’exploitation : quelle que soit la méthode, consigner au démarrage, dans les journaux, quel certificat (empreinte, échéance) a été sélectionné. Cette seule ligne se révèle précieuse aussi bien pour l’investigation d’incident que pour le recoupement avec le registre.

8. La relation avec les certificats de signature de code — le magasin « Éditeurs de confiance »

Jusqu’ici, il n’a été question que de certificats pour la communication (TLS), mais le magasin de certificats abrite aussi un autre monde : la signature de code. Le point de contact est le magasin « Éditeurs de confiance » (TrustedPublisher) vu dans le tableau de 2.2, l’endroit où l’on enregistre comme approuvés les certificats des éditeurs de logiciels signés. Il existe à la fois côté utilisateur et côté ordinateur¹⁰, et sert par exemple à distribuer, via GPO, l’éditeur d’une application interne dans le TrustedPublisher de chaque PC.

Si vous êtes du côté qui « distribue » l’application et devez gérer la signature de code ou l’avertissement SmartScreen (« Windows a protégé votre PC »), nous avons traité le sujet dans un autre article, « Pourquoi Windows affiche « Windows a protégé votre PC » ». Les connaissances de cet article-ci (les deux familles de magasins, la distribution de la racine) s’y appliquent directement comme prérequis.

9. Conclusion

• Le magasin de certificats se décline en deux familles : utilisateur (CurrentUser) et ordinateur (LocalMachine). certmgr.msc, certlm.msc et le lecteur Cert: sont trois fenêtres sur la même chose. Le premier pas d’une investigation est de s’assurer qu’on parle bien du même magasin.
• L’emplacement se décide selon « sous quelle identité s’exécute le programme ». En principe, magasin ordinateur pour l’exécution sans surveillance (service, IIS, tâche), magasin utilisateur pour une application interactive.
• « Ça fonctionnait en développement mais on ne le trouve plus en production » vient du fait que le magasin utilisateur du développeur et celui du compte de service sont deux choses distinctes. On résout cela en alignant tout sur le magasin ordinateur et StoreLocation.LocalMachine.
• Le placement dans le magasin de l’ordinateur et l’attribution du droit de lecture via « Gérer les clés privées » vont toujours de pair. N’oubliez pas de refaire l’attribution à chaque renouvellement.
• L’importation d’un pfx est non exportable par défaut. N’utilisez -Exportable que lorsque c’est vraiment nécessaire. Incluez aussi dans la conception la conservation du pfx d’origine et de son mot de passe.
• Prévenez les expirations par un inventaire régulier avec Get-ChildItem Cert: ... -ExpiringInDays et un registre des certificats. Le remplacement suit l’ordre « ajouter → basculer → vérifier → supprimer », en veillant à ne pas oublier de mettre à jour l’empreinte en configuration.
• Pour diagnostiquer la chaîne, utilisez certutil -urlfetch -verify. Distribuez la racine d’une AC interne via GPO/Intune, et réservez tout placement d’un certificat auto-signé en racine aux environnements de test, avec une durée de validité limitée.
• Dans le code, externalisez l’empreinte en configuration et journalisez le certificat sélectionné. Cela seul transforme radicalement la gestion des pannes liées aux certificats.

Articles connexes

• Pourquoi Windows affiche « Windows a protégé votre PC »
• Stockage des informations sensibles d’une application Windows — éviter les configurations en clair avec DPAPI
• La gestion sécurisée des identifiants avec PowerShell — bannir les mots de passe en clair des scripts
• Pourquoi il ne faut pas envelopper HttpClient dans un using — la pratique des communications HTTP dans les applications métier C#
• Que se passe-t-il quand on présente sa carte Mynumber comme carte d’assurance maladie ? — lire l’intégration entre la vérification en ligne des droits et le logiciel de facturation médicale à travers le code source d’ORCA

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge le développement d’applications métier intégrant une communication Web API avec certificat client (API bancaires, vérification en ligne des droits d’assurance maladie, etc.), l’investigation d’incidents du type « certificat introuvable » ou « impossible de se connecter après un renouvellement », et la mise en place de procédures de remplacement de certificats. N’hésitez pas à nous consulter même si vous ne savez pas encore quel magasin regarder.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre certmgr.msc et certlm.msc ?

Ce n'est pas le même magasin qui est visé. certmgr.msc ouvre le magasin de certificats de l'utilisateur actuellement connecté (utilisateur actuel, CurrentUser), tandis que certlm.msc ouvre le magasin de certificats de l'ordinateur (ordinateur local, LocalMachine). Le magasin de l'ordinateur est commun à tous les utilisateurs et à tous les services de ce PC, et sa gestion nécessite des droits d'administrateur. Un utilisateur non administrateur ne peut gérer que son propre magasin utilisateur. Dans les deux cas, le contenu est réparti entre magasins logiques tels que « Personnel » ou « Autorités de certification racines de confiance », et depuis PowerShell on retrouve la même structure sous Cert:\CurrentUser et Cert:\LocalMachine.

Un certificat client doit-il aller dans le magasin utilisateur ou dans le magasin ordinateur ?

Cela dépend de l'identité sous laquelle s'exécute le programme qui utilise ce certificat. Pour une application de bureau lancée par un utilisateur interactif, le magasin utilisateur de la personne concernée (Cert:\CurrentUser\My) est la base. Pour un programme qui s'exécute sans surveillance — service Windows, pool d'applications IIS, tâche du Planificateur de tâches — placez le certificat dans le magasin de l'ordinateur (Cert:\LocalMachine\My) et attribuez à son compte d'exécution le droit de lecture sur la clé privée. Le magasin utilisateur étant propre à chaque compte, un certificat qu'un développeur a placé dans son propre magasin utilisateur reste invisible pour un service qui s'exécute sous un autre compte. C'est la cause type de l'incident « ça fonctionnait en développement mais on ne le trouve plus en production ».

Que faut-il vérifier quand un service Windows ne trouve pas ou ne peut pas utiliser un certificat ?

La vérification se fait en deux temps. D'abord, quel magasin est consulté : si le code ouvre StoreLocation.CurrentUser, c'est le magasin utilisateur du compte d'exécution du service, qui n'a rien à voir avec le magasin que l'administrateur consulte dans certmgr.msc. Déplacez le certificat vers le magasin de l'ordinateur et alignez le code sur StoreLocation.LocalMachine. Ensuite, la clé privée est-elle lisible : voir le certificat dans la liste et pouvoir utiliser sa clé privée sont deux choses différentes ; par défaut, seuls les administrateurs et SYSTEM peuvent généralement accéder à la clé privée d'un certificat du magasin de l'ordinateur. Dans certlm.msc, ouvrez « Gérer les clés privées » depuis le certificat concerné et accordez le droit « Lecture » au compte d'exécution du service (NETWORK SERVICE, par exemple).

Comment détecter à l'avance, avec PowerShell, l'expiration d'un certificat ?

Vous pouvez faire cet inventaire avec Get-ChildItem sur le lecteur Cert:. Par exemple, Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter liste le magasin personnel de l'ordinateur trié par date d'expiration. Le paramètre -ExpiringInDays permet en plus d'extraire uniquement les certificats qui expirent dans le nombre de jours indiqué ; avec 0, ce sont les certificats déjà expirés qui ressortent. En exécutant cela mensuellement sur tous les serveurs et en croisant le résultat avec un registre des certificats, on évite quasiment tous les incidents du type « impossible de se connecter dès le matin à cause d'un certificat expiré ».

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.