Qu'est-ce qu'un magasin de confiance ? Le guide co...

Vue d'ensemble

Un magasin de confiance est un référentiel de certificats approuvés qu'un système utilise pour décider si une connexion entrante, un document signé ou un logiciel doit être considéré comme fiable. Chaque fois que votre navigateur valide un certificat HTTPS, chaque fois qu'une application Java établit une connexion TLS et chaque fois qu'un serveur authentifie un client via du TLS mutuel, un magasin de confiance est consulté en coulisses.

Le magasin de confiance contient les certificats de CA racines et les certificats de CA intermédiaires qu'une application ou un système d'exploitation considère comme faisant autorité. Si un certificat présenté lors d'une poignée de main TLS remonte à un certificat présent dans le magasin de confiance, la connexion se poursuit. Dans le cas contraire, elle est rejetée. Ce mécanisme simple constitue le socle de toute la confiance fondée sur les certificats, sur Internet comme dans les réseaux d'entreprise.

Malgré ce rôle critique, les magasins de confiance comptent parmi les composants les plus mal compris et les plus mal gérés de la PKI. Les équipes confondent magasins de confiance et magasins de clés, oublient que chaque plateforme maintient son propre magasin de confiance et négligent de les mettre à jour lorsque des certificats de CA expirent ou sont révoqués. Ce guide explique ce qu'est un magasin de confiance, en quoi il diffère d'un magasin de clés, comment les magasins de confiance fonctionnent sur chaque grande plateforme, et comment les gérer à l'échelle de l'entreprise.

Qu'est-ce qu'un magasin de confiance ?

Un magasin de confiance est un fichier ou un référentiel système qui contient un ensemble organisé de certificats numériques émis par des autorités de certification que le système considère comme fiables. Lorsqu'une application doit vérifier l'identité d'une partie distante, elle contrôle si le certificat présenté a été émis par une CA dont le certificat figure dans le magasin de confiance.

Le magasin de confiance ne contient pas de clés privées. Il ne contient que des certificats publics, plus précisément les certificats de CA racines et de CA intermédiaires qui font office d'ancres de confiance. C'est la distinction essentielle entre un magasin de confiance et un magasin de clés. Un magasin de confiance répond à une seule question : « Dois-je faire confiance à ce certificat ? » Il y répond en vérifiant que la chaîne de confiance du certificat aboutit à une CA racine présente dans le magasin.

Chaque équipement que vous utilisez possède au moins un magasin de confiance. Votre navigateur en possède un. Votre système d'exploitation en possède un. Votre environnement Java en possède un. Vos images de conteneur en possèdent un. Chacun de ces magasins de confiance est géré indépendamment, ce qui signifie qu'ils peuvent contenir des ensembles de CA différents et produire des décisions de confiance différentes pour un même certificat.

Magasin de confiance et magasin de clés

La confusion entre magasins de confiance et magasins de clés est l'une des sources les plus fréquentes d'erreurs de configuration TLS, en particulier dans les environnements Java où les deux sont stockés dans le même format de fichier (JKS ou PKCS#12).

La relation est directionnelle. Lorsque votre serveur reçoit une connexion TLS entrante, il extrait son propre certificat du magasin de clés pour le présenter au client. Lorsque votre client se connecte à un serveur, il utilise le magasin de confiance pour valider le certificat du serveur. En TLS mutuel, les deux parties utilisent les deux magasins : chacune présente un certificat issu de son magasin de clés et valide celui de l'autre via son magasin de confiance.

Une erreur fréquente consiste à importer un certificat de CA dans le magasin de clés au lieu du magasin de confiance, ou à importer la clé privée d'un serveur dans le magasin de confiance. Ces deux erreurs provoquent des défaillances TLS difficiles à diagnostiquer car les messages d'erreur sont souvent génériques (« PKIX path building failed » ou « unable to find valid certification path »).

Magasin de confiance

Contient les certificats des CA auxquelles l'application fait confiance. Ce sont uniquement des certificats publics, sans clés privées. Le magasin de confiance est utilisé pendant la validation des certificats pour déterminer si celui présenté par une partie distante doit être accepté. En Java, il est référencé par la propriété système `javax.net.ssl.trustStore`.

Magasin de clés

Contient l'identité propre de l'application : sa clé privée et son certificat (ou sa chaîne de certificats). Le magasin de clés est utilisé lorsque l'application doit prouver sa propre identité à une partie distante, par exemple lorsqu'un serveur présente son certificat TLS ou lorsqu'un client s'authentifie via du TLS mutuel. En Java, il est référencé par la propriété système `javax.net.ssl.keyStore`.

Comment les magasins de confiance fonctionnent dans TLS

Le magasin de confiance joue un rôle précis au cours de la poignée de main TLS. Comprendre exactement à quel moment et comment il est consulté permet d'expliquer pourquoi ses erreurs de configuration produisent les erreurs constatées.

C'est la raison pour laquelle l'ajout du certificat racine d'une CA privée à votre magasin de confiance est indispensable lorsque vous utilisez des certificats émis en interne. Sans cette étape, toute connexion TLS vers des services utilisant cette CA privée échouera avec une erreur de confiance.

Le serveur présente sa chaîne de certificats

Pendant la poignée de main TLS, le serveur envoie son certificat final ainsi que tous les certificats de CA intermédiaires nécessaires à la construction de la chaîne. Le serveur n'envoie pas le certificat de CA racine, car le client est censé déjà l'avoir dans son magasin de confiance.

Le client construit la chaîne

La bibliothèque TLS du client prend le certificat final du serveur et tente de construire un chemin remontant à travers les CA intermédiaires jusqu'à une CA racine. Elle utilise les certificats intermédiaires fournis par le serveur, complétés le cas échéant par les intermédiaires mis en cache localement.

Le client contrôle chaque certificat

À chaque niveau de la chaîne, le client vérifie la signature numérique, confirme que le certificat n'a pas expiré, contrôle que les extensions Key Usage et Basic Constraints autorisent son rôle dans la chaîne, et effectue les vérifications de révocation via CRL ou OCSP.

Le client compare la racine au magasin de confiance

Étape finale et décisive : le client recherche le certificat de la CA racine dans son magasin de confiance. Si la racine est présente et que sa signature sur le certificat de la CA intermédiaire est valide, la chaîne est approuvée. Si la racine est absente, l'ensemble de la chaîne est rejeté, quelle que soit la réussite des autres contrôles.

Magasins de confiance par plateforme

Les différents systèmes d'exploitation, environnements d'exécution et applications gèrent leur propre magasin de confiance, chacun avec son format, son emplacement et ses outils de gestion. Cette fragmentation est une source majeure de complexité opérationnelle en environnement d'entreprise.

### Magasin de confiance Java (JKS et PKCS#12)

Le magasin de confiance Java est un fichier, traditionnellement au format JKS (Java KeyStore), nommé `cacerts` et situé dans l'environnement d'exécution Java à `$JAVA_HOME/lib/security/cacerts`. Depuis Java 9, PKCS#12 est devenu le type de magasin de clés par défaut pour les nouveaux magasins, même si la plupart des installations existantes utilisent encore JKS.

Le mot de passe par défaut du magasin de confiance Java est `changeit`. Sa gestion s'effectue avec l'utilitaire en ligne de commande `keytool` :

- Lister les certificats approuvés : `keytool -list -keystore $JAVA_HOME/lib/security/cacerts` - Importer un certificat de CA : `keytool -importcert -alias myca -file ca.pem -keystore $JAVA_HOME/lib/security/cacerts` - Supprimer un certificat de CA : `keytool -delete -alias myca -keystore $JAVA_HOME/lib/security/cacerts`

Les applications Java utilisent le magasin de confiance indiqué par `javax.net.ssl.trustStore`. Si aucun n'est spécifié, la JVM se replie sur le fichier `cacerts` du JRE actif. Cela signifie que différentes applications Java sur un même hôte peuvent utiliser des magasins de confiance distincts, et qu'une mise à niveau du JRE peut réinitialiser le magasin de confiance à ses valeurs par défaut, supprimant tous les certificats de CA personnalisés que vous y aviez ajoutés.

### Magasin de certificats Windows

Windows utilise un magasin de certificats à l'échelle du système, géré via la Microsoft Management Console (MMC) ou l'outil en ligne de commande `certutil`. Le magasin de confiance correspond à la zone « Autorités de certification racines de confiance », accessible via `certmgr.msc` pour l'utilisateur courant ou `certlm.msc` pour la machine locale.

Windows présente un comportement particulier : il n'est pas livré avec tous les certificats racines préinstallés. Il s'appuie sur le Microsoft Trusted Root Certificate Program et télécharge les certificats racines à la demande depuis Windows Update lors de leur première utilisation. Ce comportement peut provoquer des défaillances de confiance inattendues sur des systèmes isolés du réseau ou sur des machines qui ne peuvent pas atteindre Windows Update.

Les administrateurs distribuent les certificats de CA personnalisés au magasin de confiance Windows via des objets de stratégie de groupe (GPO), ce qui permet une gestion centralisée de la confiance sur des milliers de machines. C'est le mécanisme standard pour faire approuver une CA privée dans un environnement de domaine Windows.

### Magasin de confiance macOS (Keychain)

Sur macOS, le magasin de confiance est géré via l'application Trousseau d'accès (Keychain Access) ou l'outil en ligne de commande `security`. Les racines de confiance au niveau du système sont stockées dans le trousseau System Roots à `/System/Library/Keychains/SystemRootCertificates.keychain`. Les certificats de CA personnalisés sont généralement ajoutés au trousseau System.

Ajouter une CA au magasin de confiance macOS requiert deux étapes : importer le certificat, puis définir explicitement sa stratégie de confiance sur « Toujours approuver ». Le simple import du certificat ne suffit pas. Dans les environnements gérés par MDM, des profils de configuration peuvent déployer des certificats de CA approuvés sur l'ensemble du parc macOS.

macOS gère son propre programme de racines (le Apple Root Certificate Program), indépendant des programmes Mozilla ou Microsoft. Cela signifie qu'une CA approuvée sous Windows peut ne pas l'être sous macOS, et inversement.

### Magasin de confiance Linux

Les distributions Linux stockent les certificats de CA approuvés sous forme de fichiers PEM dans un répertoire système, mais l'emplacement exact et l'outil de gestion varient selon la distribution :

- Debian/Ubuntu : certificats dans `/usr/local/share/ca-certificates/`, gérés avec `update-ca-certificates` - RHEL/CentOS/Fedora : certificats dans `/etc/pki/ca-trust/source/anchors/`, gérés avec `update-ca-trust` - Alpine : certificats dans `/usr/local/share/ca-certificates/`, gérés avec `update-ca-certificates`

Le bundle de confiance consolidé est généralement écrit dans `/etc/ssl/certs/ca-certificates.crt` (Debian) ou `/etc/pki/tls/certs/ca-bundle.crt` (RHEL). Les applications qui utilisent OpenSSL ou GnuTLS s'appuient sur ce bundle par défaut.

Les images de conteneur méritent une attention particulière. Une image Docker minimale peut inclure un magasin de confiance allégé, voire aucun. Si votre application conteneurisée doit faire confiance à une CA privée, vous devez ajouter le certificat de la CA au magasin de confiance du conteneur lors du build de l'image. Oublier cette étape compte parmi les causes les plus fréquentes de défaillances TLS dans les environnements conteneurisés.

### Magasins de confiance des navigateurs

Les navigateurs gèrent leurs propres décisions de confiance, et tous n'utilisent pas le magasin de confiance du système d'exploitation :

- Chrome et Edge utilisent le magasin de confiance du système d'exploitation sous Windows et macOS, mais Chrome applique des contraintes supplémentaires via le Chrome Root Program et les exigences de Certificate Transparency. - Firefox utilise son propre magasin de confiance intégré (le magasin Mozilla NSS), indépendant du système d'exploitation. Un certificat de CA ajouté au magasin de confiance Windows ou macOS ne sera pas reconnu par Firefox, sauf à être importé séparément dans le gestionnaire de certificats de Firefox ou déployé via une stratégie d'entreprise. - Safari utilise exclusivement le magasin de confiance système de macOS ou d'iOS.

Cela signifie que dans un environnement d'entreprise, déployer le certificat d'une CA privée uniquement dans le magasin de confiance du système d'exploitation ne suffit pas si les collaborateurs utilisent Firefox. Vous devez également le déployer via les stratégies d'entreprise Firefox ou utiliser l'outil `certutil` pour modifier la base NSS de Firefox.

Gérer les magasins de confiance à l'échelle de l'entreprise

Dans un petit environnement, ajouter manuellement un certificat de CA à quelques magasins de confiance reste gérable. Dans une entreprise avec des milliers de serveurs, plusieurs systèmes d'exploitation, des charges conteneurisées et une grande diversité de piles applicatives, la gestion des magasins de confiance devient un défi opérationnel majeur.

Les problèmes principaux sont la fragmentation et la dérive. Une même organisation peut avoir à gérer des magasins de confiance sur des serveurs Windows (magasin système), des serveurs Linux (magasins propres à la distribution), des applications Java (fichiers cacerts par JRE), des conteneurs (magasins au niveau de l'image), des postes de développement (magasins du système d'exploitation et du navigateur) et des terminaux mobiles (profils gérés par MDM). Chacun de ces magasins doit contenir le même ensemble de CA approuvées pour un comportement cohérent, et pourtant chacun utilise un format et un mécanisme de gestion différents.

Distribution centralisée des certificats de CA

Utilisez des outils de gestion de configuration (Ansible, Puppet, Chef, SCCM) pour déployer les certificats de CA approuvés dans chaque magasin de confiance de votre infrastructure. Définissez la liste de référence des CA approuvées en un seul endroit, puis poussez-la vers toutes les plateformes. Cela évite les dérives où certains systèmes font confiance à une CA et d'autres non.

Audit des magasins de confiance

Auditez régulièrement vos magasins de confiance pour vérifier qu'ils contiennent exactement les CA que vous souhaitez approuver, ni plus ni moins. Les certificats de CA orphelins, issus de CA internes mises hors service ou de CA publiques révoquées, doivent être retirés rapidement. Chaque ancre de confiance inutile est une surface d'attaque inutile.

Conscience du cycle de vie

Les certificats de CA ont des dates d'expiration, généralement de 10 à 25 ans pour les CA racines. Lorsqu'un certificat de CA racine présent dans votre magasin de confiance expire, tous les certificats émis sous cette CA cessent d'être approuvés. Suivez les dates d'expiration des certificats de CA dans le cadre de la gestion du cycle de vie de votre PKI.

Confiance de moindre privilège

N'acceptez pas le magasin de confiance par défaut tel quel. Les magasins de confiance par défaut contiennent des centaines de CA racines, dont beaucoup n'interagiront jamais avec votre organisation. Pour les environnements à forte exigence de sécurité, envisagez de réduire le magasin de confiance aux seules CA réellement nécessaires. Cela diminue le risque qu'une CA compromise soit utilisée pour usurper vos services.

Problèmes fréquents et correctifs

Les problèmes de magasin de confiance représentent une part importante des incidents liés au TLS. Les symptômes sont généralement des messages d'erreur génériques qui ne pointent pas directement vers le magasin de confiance.

« PKIX path building failed » (Java)

C'est l'erreur typique du magasin de confiance Java. Elle signifie que la JVM n'a pas pu construire de chaîne de certificats valide depuis le certificat du serveur jusqu'à une CA racine de son magasin de confiance. Correctif : vérifiez que le serveur envoie bien la chaîne complète (intermédiaires inclus), puis confirmez la présence du certificat de la CA racine dans le fichier `cacerts` Java. Utilisez `keytool -list` pour inspecter le contenu du magasin de confiance.

« certificate verify failed » (OpenSSL/Python/Ruby)

Le bundle de confiance OpenSSL du système ne contient pas la CA racine qui a signé le certificat du serveur. Correctif : ajoutez le certificat de la CA dans le répertoire approprié et exécutez `update-ca-certificates` ou `update-ca-trust`. Pour Python en particulier, le paquet `certifi` embarque son propre magasin de confiance, qui peut différer de celui du système.

« SEC_ERROR_UNKNOWN_ISSUER » (Firefox)

Firefox ne trouve pas la CA émettrice dans son magasin de confiance NSS intégré. Cela arrive fréquemment avec des certificats de CA privées ajoutés au magasin de confiance du système d'exploitation mais pas à celui de Firefox. Correctif : importez le certificat de la CA dans le gestionnaire de certificats de Firefox ou déployez-le via une stratégie d'entreprise Firefox.

Magasin de confiance réinitialisé après une mise à jour du JRE

La mise à niveau de l'environnement Java remplace le fichier `cacerts`, supprimant les certificats de CA personnalisés que vous aviez importés. Correctif : automatisez le provisionnement du magasin de confiance afin que les CA personnalisées soient réinjectées après chaque mise à jour du JRE. Vous pouvez aussi configurer les applications pour utiliser un fichier de magasin de confiance distinct, hors du répertoire du JRE.

Échecs de confiance dans les conteneurs

Une application conteneurisée ne parvient pas à valider les certificats émis par une CA privée parce que l'image du conteneur n'inclut pas le certificat de la CA dans son magasin de confiance. Correctif : ajoutez une étape `COPY` puis `RUN update-ca-certificates` à votre Dockerfile. Pour les conteneurs Java, mettez également à jour le fichier `cacerts` du JRE à l'intérieur de l'image.

CA racine expirée dans le magasin de confiance

Un certificat de CA racine présent dans le magasin de confiance a expiré, provoquant l'échec de validation de tous les certificats émis sous cette CA. Contrairement aux certificats finaux, l'expiration d'une CA racine est rare et catastrophique. Correctif : remplacez le certificat de CA racine expiré par sa version renouvelée et redistribuez-le à tous les magasins de confiance.

Bonnes pratiques de gestion des magasins de confiance

Une gestion efficace des magasins de confiance s'appuie sur un ensemble de principes qui passent à l'échelle, d'un serveur unique à une infrastructure mondiale.

Inventorier chaque magasin de confiance

On ne peut pas gérer ce que l'on ne connaît pas. Cartographiez chaque magasin de confiance de votre environnement : au niveau du système d'exploitation, du JRE, de l'application, du conteneur et du navigateur. Identifiez les CA que chacun approuve.

Automatiser la distribution des CA

Ne dépendez jamais de processus manuels pour ajouter ou retirer des CA des magasins de confiance. Utilisez la gestion de configuration, le MDM ou les stratégies de groupe pour garantir que chaque magasin de confiance, sur chaque plateforme, reflète votre politique de confiance en vigueur.

Surveiller l'expiration des certificats de CA

Les certificats de CA racines expirent rarement, mais avec des conséquences majeures. Surveillez les dates d'expiration de chaque certificat de CA présent dans vos magasins de confiance et planifiez les rotations bien en amont.

Retirer les ancres de confiance inutiles

Les magasins de confiance par défaut embarquent des centaines de CA racines. Pour les applications internes qui ne communiquent qu'avec des services utilisant votre CA privée, envisagez un magasin de confiance minimal ne contenant que votre CA. Cela limite la portée d'une compromission de CA publique.

Versionner votre politique de confiance

Maintenez une liste de référence des CA approuvées dans votre système de gestion de versions. Traitez les modifications de cette liste comme des changements de code : passez-les en revue, approuvez-les et déployez-les via votre pipeline CI/CD.

Tester les changements en pré-production

Ajouter ou retirer une CA d'un magasin de confiance affecte chaque connexion TLS que ce système établit. Testez les changements dans un environnement de pré-production avant de les déployer en production, pour éviter des échecs de connexion inattendus.

Aligner les magasins de confiance entre plateformes

Assurez-vous que tous les magasins de confiance de votre environnement (système d'exploitation, JRE, conteneurs, navigateurs) contiennent le même ensemble de CA approuvées. Les incohérences provoquent des défaillances intermittentes, où une connexion fonctionne depuis un système mais échoue depuis un autre.

Comment nous aidons

Evertrust & Qu'est-ce qu'un magasin de confiance ? Le guide complet

Visibilité complète sur les magasins de confiance — Evertrust CLM découvre et inventorie les certificats sur l'ensemble de votre infrastructure, y compris les certificats de CA présents dans vos magasins de confiance. Sachez précisément quelles CA sont approuvées, à quels endroits et quand leurs certificats expirent.

Distribution automatisée des certificats de CA — Lors de l'ajout d'une nouvelle CA privée ou de la rotation d'un certificat racine, Evertrust s'intègre à vos outils de gestion de configuration et de MDM pour propager les mises à jour à chaque magasin de confiance, sur chaque plateforme, de manière homogène.

Gestion du cycle de vie des certificats de CA — Suivez l'expiration des certificats de CA racines et intermédiaires aux côtés de vos certificats finaux. Evertrust vous alerte bien avant qu'une expiration de CA ne se transforme en défaillance de confiance à l'échelle du système.

Application des politiques sur les magasins de confiance — Définissez les CA approuvées par votre organisation et appliquez cette politique de façon uniforme. Evertrust identifie les certificats de CA non autorisés ou inattendus dans vos magasins de confiance afin de les retirer avant qu'ils ne deviennent un risque de sécurité.

Parler à un expert Découvrir CLM

Qu'est-ce qu'un magasin de confiance ? Le guide complet

En bref