Une chaîne de confiance permet à un client de rattacher un certificat à une autorité qu’il accepte. La signature du certificat ne suffit pas : le client doit aussi contrôler le chemin de certification, les contraintes applicables et l’identité du service demandé. Une connexion chiffrée et une identité correctement vérifiée sont deux propriétés à examiner ensemble.
Les trois rôles à distinguer
Le certificat du service, souvent appelé certificat terminal, contient notamment sa clé publique et des informations d’identité. Une autorité intermédiaire signe ce certificat. Le client cherche un chemin acceptable jusqu’à une ancre de confiance configurée dans son environnement.
La RFC 5280 définit le profil des certificats X.509 et la validation du chemin de certification. Dans un déploiement habituel, les racines sont distribuées dans un magasin de confiance. Leur présence dans un message reçu ne suffit pas à les rendre dignes de confiance.
Magasin du client : ancre de confiance acceptée
│
Autorité intermédiaire
│
Certificat du service
Ce schéma est simplifié : plusieurs chemins peuvent exister. Les chaînes publiées par Let’s Encrypt montrent concrètement que racines, intermédiaires et compatibilité des clients doivent être considérés ensemble.
Ce que le client doit vérifier
La validation du chemin porte sur les signatures, les périodes de validité et les contraintes pertinentes. L’application doit également vérifier que l’identité attendue correspond au service contacté. Ce dernier point ne se déduit pas simplement de l’existence d’une signature valide.
Le RFC 9525 sur l’identité des services TLS précise les règles de représentation et de vérification des identités. Pour les déploiements, les recommandations TLS doivent être suivies avec leurs mises à jour, plutôt qu’en copiant une configuration ancienne sans examen.
Certificat valide, mauvais service
Dans un exemple pédagogique, un client attend api.example.com, mais le service présente un certificat pour admin.example.com. La chaîne peut être cryptographiquement acceptable tout en ne correspondant pas au nom demandé. Désactiver la vérification du nom pour faire disparaître l’erreur supprimerait une protection utile.
Le diagnostic doit donc distinguer au moins la confiance dans l’émetteur, la période de validité et l’identité du service. Les messages d’erreur précis permettent de ne pas traiter tous les échecs comme une simple expiration.
Pourquoi une chaîne fonctionne sur un poste et pas sur un autre
Les clients peuvent disposer de magasins de confiance différents. Une application Java, un navigateur et un programme Python ne dépendent pas nécessairement de la même configuration. Certains environnements peuvent aussi avoir conservé des intermédiaires rencontrés auparavant.
Une installation qui fonctionne uniquement sur un poste déjà utilisé ne constitue donc pas une preuve de configuration complète. Tester avec les environnements réellement supportés, y compris un client sans historique préalable, aide à identifier ces dépendances implicites.
| Symptôme | Piste à vérifier | Mauvais raccourci |
|---|---|---|
| Autorité inconnue | Racines disponibles, chemin proposé | Importer toute racine sans provenance |
| Chaîne incomplète | Intermédiaires transmis par le serveur | Tester uniquement le certificat terminal |
| Nom incorrect | Identité attendue, sélection du service | Désactiver la vérification du nom |
| Échec après renouvellement | Nouvelle chaîne, algorithmes, activation | Supposer que seule la date a changé |
PKI publique et PKI privée
Une PKI publique vise une reconnaissance par des programmes de confiance externes, selon leurs exigences. Une PKI privée implique une distribution et une maîtrise des ancres auprès des clients concernés. « Privée » ne signifie pas automatiquement « sûre » : les clés d’autorité, les procédures d’émission et les accès restent déterminants.
La décision dépend du besoin de reconnaissance, du contrôle sur les clients et des usages. Déployer une autorité privée pour éviter toute gestion de confiance déplacerait le travail vers la distribution, la rotation et le retrait des ancres.
Un contrôle pédagogique avec Python
La documentation officielle du module ssl de Python recommande un contexte de sécurité approprié ; create_default_context() fournit notamment les réglages usuels de validation pour un client. Ce fragment illustre une connexion vers un domaine d’exemple, à remplacer uniquement par un service que vous êtes autorisé à tester.
import socket
import ssl
host = "example.com"
context = ssl.create_default_context()
with socket.create_connection((host, 443), timeout=5) as tcp:
with context.wrap_socket(tcp, server_hostname=host) as tls:
certificate = tls.getpeercert()
print(certificate.get("notAfter"))
Ce contrôle utilise le magasin disponible pour cet environnement Python. Il ne remplace ni l’analyse complète d’une PKI, ni les vérifications de révocation adaptées au contexte, ni un contrôle fonctionnel de l’application. Il ne faut pas ajouter CERT_NONE pour contourner une erreur.
La confiance TLS n’est pas une autorisation métier
Une connexion TLS réussie n’accorde pas automatiquement le droit de lire un dossier, de modifier une ressource ou d’agir au nom d’un utilisateur. Ces décisions appartiennent à l’authentification et à l’autorisation applicatives, selon l’architecture retenue.
C’est le lien avec Digital Trust et identité. Pour maintenir cette confiance dans le temps, consulter le cycle de vie des certificats et le dossier TLS, PKI & certificats.