PKI et TLS

PKI et TLS

Un certificat est une promesse signée : telle clé appartient à tel nom, jusqu’à telle date, sauf révocation. Tout le reste de la PKI sert à rendre cette promesse vérifiable, et TLS à s’en servir pour ouvrir un canal chiffré avec le bon interlocuteur. Vingt ans de PKI apprennent pourtant que la cryptographie casse rarement : ce qui casse, c’est le certificat expiré dont personne n’avait noté la date, la révocation que les clients ne consultent pas, l’autorité interne dont la clé dort sur un disque partagé.

Explication de la marmotte

Une carte d’identité n’a de valeur que parce qu’une préfecture reconnue l’a délivrée et que tout le monde fait confiance à cette préfecture. Sur internet, les ordinateurs se présentent eux aussi avec des papiers officiels, délivrés par des organismes reconnus. Ce dossier explique comment ces papiers circulent et comment ils permettent de discuter en secret.

→ Lire l’explication complète de la marmotte

L’ordre de lecture proposé part des mécanismes (ce qu’est une chaîne de confiance, ce que TLS garantit et ne garantit pas), passe par la construction et l’exploitation d’une PKI, s’arrête sur la révocation, qui mérite sa propre partie tant elle fonctionne mal, et finit par TLS en production : diagnostic, migration, choix d’algorithmes et cas des clients contraints.

Comprendre les mécanismes

• PKI expliquee : chaîne de confiance, certificats et autorités de certification.
• Comprendre TLS : mécanismes, garanties et limites : négociation, confidentialité persistante, et ce que le protocole ne couvre pas.
• mTLS : l’authentification mutuelle entre services et son coût d’exploitation.
• Extensions X.509 v3 Key Usage EKU et Basic Constraints : les champs qui décident de ce qu’un certificat a le droit de faire.

Construire et exploiter une PKI

• Construire une autorité de certification privée interne : conception, protection de la racine et exploitation.
• Cycle de vie d’une autorité de certification intermédiaire : émettre, renouveler et révoquer en cascade.
• Gestion du cycle de vie des certificats à grande échelle : découvrir, renouveler, déployer et superviser.
• EST : enrôler des certificats X.509 par transport sécurisé : l’enrôlement automatique des machines, et ce qui le distingue de SCEP.
• Sécuriser la validation de domaine HTTP-01 et DNS-01 : comment une autorité publique s’assure qu’on contrôle un domaine, et comment on la trompe.
• Sécuriser ACME wildcard et external account binding : les extensions ACME et leurs contraintes.
• Quels risques pour un certificat wildcard TLS : une clé pour tous les sous-domaines, donc un seul vol pour tous.
• Surveiller Certificate Transparency pour son domaine : repérer un certificat émis au nom de son domaine sans l’avoir demandé.
• Certificats SSH et risques de l’agent forwarding : la PKI appliquée aux accès SSH.

Révocation

• CRL ou OCSP pour révoquer un certificat : listes de révocation contre statut en ligne.
• OCSP stapling pour vérifier la révocation TLS : fournir le statut au client sans requête supplémentaire.

TLS en production

• Diagnostiquer les erreurs de validation TLS en production : chaîne, nom, horloge, dans cet ordre.
• Migrer TLS legacy sans casser les clients anciens : retirer les vieilles versions sans couper les derniers clients qui en dépendent.
• Choisir ECDSA, EdDSA ou RSA pour un certificat TLS : taille de clé, performance et compatibilité.
• Pourquoi un certificat diffère selon le navigateur : les magasins de confiance ne sont pas les mêmes partout.
• Certificate pinning : risques et rotation des certificats : la protection qui transforme une rotation en panne.
• Valider un certificat serveur sur mobile et embarqué : quand le client ne peut pas mettre à jour son magasin de confiance.
• Intégrer la cryptographie post-quantique dans TLS : la migration hybride face à la récolte de trafic chiffré.
• DNS over TLS (DoT) : chiffrer la résolution de noms : TLS appliqué au transport des requêtes DNS.

Dans la rubrique Cryptographie

• Relier une clé à une identité: certificats et PKI : le fondement cryptographique des certificats.
• Sécuriser un canal: TLS, HTTPS et mTLS : TLS vu depuis les primitives qu’il assemble.

🐝 Ce qui arrive si on s’en passe

Une organisation qui néglige ce domaine laisse expirer des certificats sans le savoir, et découvre la panne quand un service refuse soudain toute connexion. Plus grave, un canal dont l’identité du serveur n’est pas vérifiée reste chiffré tout en parlant peut-être à un imposteur : le chiffrement protège alors fidèlement la conversation avec l’attaquant. Sans autorité de certification maîtrisée, personne ne sait qui peut émettre un certificat au nom de l’organisation, ni comment retirer celui dont la clé a fuité. La ruche finit par ouvrir sa porte à quiconque arbore un badge bien imprimé.

🦫 Explication de la marmotte 🍫

Ce dossier traite de deux mécanismes liés. Le premier est l’infrastructure à clés publiques. Chaque serveur ou service possède une paire de clés : une clé privée qu’il garde, et une clé publique qu’il montre. Pour prouver que cette clé publique lui appartient vraiment, une autorité de certification signe un document appelé certificat, qui associe la clé à un nom. Les appareils font confiance à une courte liste d’autorités, et vérifient la chaîne de signatures qui remonte jusqu’à l’une d’elles. Le second mécanisme est le protocole de transport sécurisé, appelé TLS. Au début d’une connexion, le serveur présente son certificat ; le client vérifie la signature, le nom et la date de validité, puis les deux parties fabriquent ensemble des clés temporaires qui chiffrent et protègent la suite de l’échange. Si le certificat est expiré, mal signé ou ne correspond pas au nom demandé, la connexion doit être refusée. Dans l’authentification mutuelle, appelée mTLS, le client présente lui aussi un certificat, que le serveur vérifie de la même façon : les deux côtés prouvent leur identité. Le dossier commence par ces mécanismes, explique ensuite comment construire et faire vivre une autorité de certification, puis comment retirer un certificat avant son terme, ce qu’on appelle la révocation et qui fonctionne beaucoup moins bien qu’on ne le croit. Il finit par les difficultés de TLS en production : erreurs de validation, anciens clients à ménager, choix des algorithmes, appareils qui ne se mettent jamais à jour.