Ancres de confiance et magasins de confiance

Portail > PKI et autorités de certification

Une chaîne ne se valide que si elle aboutit à une ancre de confiance — un certificat auquel on fait confiance a priori. L'ensemble de ces ancres constitue un magasin de confiance (trust store). Sans ancre, aucune signature ne peut être tenue pour digne de confiance.

Ancre de confiance

Une ancre de confiance (trust anchor) est typiquement le certificat d'une autorité racine, auto-signé. On ne vérifie pas sa signature en remontant plus haut : on lui fait confiance par décision/configuration. C'est le point d'arrêt de la validation du chemin.

La confiance ne porte donc pas sur la signature de la racine (qu'elle s'est donnée elle-même), mais sur le fait qu'elle figure dans un magasin de confiance maîtrisé.

Magasins de confiance

Chaque environnement maintient son propre magasin :

Environnement	Magasin
Linux (système)	/etc/ssl/certs, paquet ca-certificates
Windows	Magasin de certificats Windows (Trusted Root Certification Authorities)
macOS / iOS	Keychain / Trust Store Apple
Navigateurs	Magasin OS ou magasin propre (Firefox a le sien)
Java	cacerts (keystore JKS/PKCS12)
Langages / runtimes	Souvent un bundle dédié (ex. certifi côté Python)

Conséquence pratique : un certificat « valide dans le navigateur » peut échouer dans un service Java, un conteneur, un script Python ou un client mTLS si leur magasin ne contient pas la racine. Le diagnostic des chaînes doit toujours préciser « de confiance pour qui ? ».

Programmes racine (PKI publique)

Pour le Web ouvert, ce sont des programmes racine qui décident des racines de confiance par défaut : Mozilla, Microsoft, Apple, Google (Chrome Root Program). Une autorité publique doit satisfaire leurs exigences d'audit pour que sa racine soit pré-installée. C'est ce qui rend un certificat Let's Encrypt ou DigiCert accepté « sans rien configurer ».

Magasins privés / PKI interne

Pour une PKI interne, la racine n'est dans aucun programme public : il faut la déployer soi-même dans le magasin des machines concernées.

# Debian/Ubuntu : ajouter une racine interne au magasin système
sudo cp racine-interne.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# RHEL/Fedora/CentOS
sudo cp racine-interne.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract

# Java (keystore cacerts)
keytool -importcert -alias racine-interne -file racine-interne.crt \
        -keystore "$JAVA_HOME/lib/security/cacerts"

C'est précisément l'oubli de cette étape dans un nouvel environnement (conteneur, runner CI, nouveau nœud) qui produit les erreurs « unable to get local issuer certificate ».

Modèles de confiance alternatifs

• Hiérarchique (X.509/PKI) : ancres = racines ; modèle dominant, traité ici.
• Réseau de confiance (web of trust, PGP/GnuPG) : pas d'autorité centrale, les utilisateurs se signent mutuellement.
• TOFU / épinglage (Trust On First Use / pinning) : on mémorise un certificat/clé au premier contact (ex. SSH, épinglage applicatif) et on alerte en cas de changement.

Épinglage (pinning)

L'épinglage consiste à exiger un certificat ou une clé précis (par son empreinte), au-delà de la simple validation de chaîne. Renforce la sécurité mais complique fortement les renouvellements/rotations : un changement de clé non anticipé casse la connexion.

Points clés à retenir

• L'ancre de confiance (racine) est crue par configuration, pas vérifiée par signature : c'est le point d'arrêt de la validation.
• Il n'existe pas « un » magasin : OS, navigateurs, Java, runtimes en ont chacun un → « de confiance pour qui ? ».
• PKI publique : programmes racine (Mozilla, Apple, Microsoft, Google). PKI interne : déployer la racine soi-même.
• Oublier d'installer la racine interne = erreur « local issuer certificate ».

Voir aussi

• Autorités de certification
• Validation du chemin de certification
• Dépannage des chaînes de certificats