OpenVPN sans CA : comment peer-fingerprint vérifie les pairs

Un petit déploiement se tourne vers les empreintes parce qu'une autorité de certification ressemble à une infrastructure pour laquelle personne n'a le temps. L'instinct est raisonnable, mais le raccourci que les gens prennent à la place—copier un secret du canal de données aux deux extrémités—ne l'est pas. Une configuration peer-fingerprint garde la structure TLS intacte : chaque côté conserve toujours sa propre clé privée et son certificat, et chaque côté vérifie toujours l'autre. Ce qui change, c'est où la vérification est ancrée : d'un émetteur de confiance à une courte liste de condensats épinglés. Comme un condensat couvre le certificat entier et non un nom, le renouvellement devient l'opération qui coûte vraiment du temps.

À quoi l'empreinte s'engage réellement

L'empreinte d'un certificat est un condensat du certificat entier encodé en DER, pas de sa clé publique et pas du nom de son sujet. Deux certificats aux noms identiques et à la même clé mais à des dates de validité différentes ont donc des empreintes différentes. C'est ce qui rend l'épinglage précis, et c'est aussi ce qui rend le renouvellement perturbant. Un épinglage ne peut pas signifier faire confiance à une clé en général, car il nomme un artefact à un moment de sa vie. N'importe qui peut connaître le condensat, et le connaître ne prouve rien en soi.

openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256

La possession de la clé privée correspondante est ce qui prouve que le pair détient ce certificat, et le condensat est la façon dont l'autre côté décide s'il attendait ce certificat. Cette séparation est la raison pour laquelle cette conception n'est pas l'ancien arrangement à secret partagé : une clé partagée authentifie quiconque connaît les mêmes octets, tandis qu'un épinglage authentifie un certificat. Un appareil différent obtient sa propre entrée plutôt qu'une copie du même secret, ce qui est une petite différence dans les fichiers et une grande dans l'étendue des dégâts.

La carte est réciproque, pas symétrique

Chaque extrémité a besoin de deux choses : sa propre clé privée avec le certificat, et une déclaration sur les certificats de pairs qu'elle acceptera. Chez le client, cette déclaration est le condensat du certificat du serveur ; chez le serveur, c'est la liste des condensats des clients inscrits. Un exemple officiel pour les petites configurations de Community 2.6 montre l'arrangement avec peer-fingerprint, et il vaut la peine de le lire avant de choisir ce modèle de confiance pour un déploiement réel. Les deux directions ne sont pas une liste inversée, et elles n'échouent pas au même moment.

Ajouter un appareil modifie une liste d'autorisation sur le serveur, sans copier le matériel privé d'un client existant et sans déplacer la clé du serveur nulle part. Les deux directions échouent aussi indépendamment, ce qui est utile pendant le diagnostic : le côté qui ferme le handshake est le côté dont l'attente n'a pas été satisfaite. Si le client rejette le serveur, le condensat ne correspond pas au certificat présenté. Si le serveur rejette le client, le condensat de ce client manque dans la liste, ou le client présente un certificat différent de celui qui a été inscrit.

Inscription : comment un nouvel appareil rejoint

Générez la clé et le certificat du nouvel appareil là où la clé privée vivra, puis déplacez seulement l'artefact public vers la partie qui doit l'épingler. Transférez le condensat attendu par un canal auquel vous faites déjà confiance, et comparez le certificat complet plutôt qu'un nom qui semble familier. Un condensat copié depuis le même téléchargement non vérifié que le certificat ne prouve que les deux fichiers concordent entre eux. C'est une vérification de cohérence et non d'identité, et c'est la façon la plus silencieuse dont cette conception s'affaiblit.

Sur le serveur, ajouter le condensat est un changement de configuration qui passe par le gestionnaire habituel et est suivi d'une reconnexion. Confirmez que le nouvel appareil se connecte et qu'un appareil dont le condensat a été retiré ne le fait plus. Un test qui ne couvre que le cas positif laisse la liste d'autorisation non vérifiée, et c'est exactement l'état dans lequel vous serez dans six mois.

Le renouvellement est le moment coûteux

Chaque certificat expire, et un nouveau certificat a un nouveau condensat même lorsque la clé et les noms restent les mêmes. Sous un émetteur, le renouvellement est transparent pour les pairs qui font confiance à cet émetteur ; sous l'épinglage, c'est un événement d'inscription pour chaque pair qui épingle le certificat.

Planifiez l'ordre avant la date d'expiration plutôt qu'après. Distribuez le nouveau condensat aux parties qui le vérifient, appliquez le changement, et seulement ensuite remplacez le certificat sur l'extrémité. Cet ordre ne laisse aucune fenêtre où les deux côtés sont en désaccord sur le certificat en cours. Maintenez aussi la liste elle-même sous revue, car une liste épinglée accumule des entrées pour des appareils retirés il y a des mois. Chaque entrée obsolète est une identité qui s'authentifie encore si sa clé survit, donc en supprimer une est une action de sécurité et non du rangement.

Ce que la carte de confiance ne décide pas

L'authentification est une couche, et la carte épinglée ne dit rien sur le pool d'adresses, les routes poussées, la MTU du chemin ou la politique du pare-feu. Ces éléments restent une configuration séparée avec des modes de défaillance séparés. Un tunnel qui s'authentifie et ne passe aucun trafic est une enquête différente de celui qui ne monte jamais.

La carte ne s'étend pas non plus indéfiniment, et une PKI fondée sur un émetteur est là où aboutissent les déploiements plus grands. Cette préférence concerne l'exploitation et non la cryptographie, car ajouter et retirer des identités via une seule autorité coûte moins cher que modifier une liste sur chaque pair à mesure que la flotte grandit. Lorsqu'une implémentation client ne prend pas en charge l'option, la réponse est un modèle de confiance compatible que ce client documente, ou un remplacement pris en charge. Masquer l'avertissement de vérification n'ajoute pas ce support, et toute la valeur de la conception est que la vérification a toujours lieu.