Nebula a besoin de trois fichiers : CA, certificat d’hôte, clé d’hôte

Si vous donnez à quelqu’un un répertoire Nebula, il copie généralement tout, y compris le fichier qui ne devrait jamais quitter votre poste de travail. La confusion est compréhensible, car les trois fichiers du bloc PKI d’un hôte se ressemblent et deux d’entre eux sont des certificats. Chacun répond à une question différente, et seuls deux appartiennent au nœud. Classez-les par rôle avant de copier quoi que ce soit.

Trois fichiers, trois rôles différents

Le certificat CA est une ancre de confiance : il indique à un hôte quelles autorités croire lorsqu’un autre hôte présente son identité. Le certificat d’hôte est l’accréditation propre au nœud, signée par cette autorité. La clé d’hôte est la moitié privée correspondante, et elle appartient à une seule machine. Un nœud muni du certificat CA et de sa propre paire peut rejoindre l’overlay et prouver qui il est. Un nœud muni de la clé d’autrui peut aussi se faire passer pour cette personne, et c’est précisément la défaillance que cette organisation doit empêcher.

Copier un répertoire d’hôte fonctionnel sur une seconde machine n’est donc pas un raccourci. C’est une identité dupliquée au résultat prévisible.

La clé de signature ne voyage jamais

La clé de signature de la CA ne fait partie d’aucune configuration d’hôte. Elle fabrique de nouvelles identités, et qui la détient peut émettre un certificat pour n’importe quelle adresse overlay et n’importe quel groupe. Les pairs n’ont besoin que du certificat CA public pour vérifier les signatures, donc la moitié privée n’a aucun rôle sur un client. Gardez-la sur la machine où les certificats sont émis, et traitez une copie accidentelle comme un incident, non comme une commodité.

Si plusieurs personnes doivent émettre des certificats, donnez-leur un processus plutôt qu’une copie de la clé. Une clé de signature partagée sur un portable est une autorité que personne ne peut auditer ni révoquer.

Ce que contient un certificat d’hôte

Un certificat d’hôte lie à une clé bien plus qu’un nom de fichier. Il porte l’adresse du nœud dans l’overlay, son nom et son appartenance à un groupe, le tout signé pour qu’un pair puisse décider de l’accepter. C’est pourquoi renommer un hôte signifie émettre un nouveau certificat et non modifier une ligne de configuration.

nebula-cert print -path host.crt montre ce qui a réellement été émis. Lisez-le avant de supposer qu’un certificat porte l’adresse que vous vouliez.

Un rechargement ne suffit pas toujours

Certains réglages PKI se rechargent sur un signal, d’autres non. Un certificat dont l’adresse overlay a changé est le cas classique qui exige un redémarrage du processus plutôt qu’un rechargement.

Vérifiez quels chemins le processus en cours a réellement ouverts, pas seulement ceux que nomme le fichier de configuration. Changez ensuite une accréditation, vérifiez la connectivité et les journaux, et seulement alors passez à la suivante. Un rechargement qui semble réussir alors que l’ancien certificat reste en mémoire produit une incohérence qui ressemble à un problème de routage. Redémarrer coûte peu ; déboguer une identité que la moitié de l’overlay voit encore à l’ancienne ne coûte pas peu.

Retirer une identité exige une liste de blocage

Remplacer une accréditation perdue ou exposée comporte deux moitiés. Le nouveau certificat rétablit l’accès, et l’ancienne identité doit cesser d’être acceptée. Ce sont des opérations distinctes, et n’effectuer que la première laisse l’accréditation compromise valide.

La liste de blocage est un fichier que vous distribuez aux hôtes, pas quelque chose qu’un lighthouse pousse de lui-même. Prévoyez comment elle atteint chaque nœud, y compris ceux qui sont hors ligne aujourd’hui, et notez quelles empreintes vous avez bloquées. Effectuez une rotation de la clé sur la machine émettrice et conservez les détails du nouveau certificat avec la fiche de l’hôte. Une révocation qui n’existe que sur la machine que vous avez modifiée n’est pas une révocation.