Nebula braucht drei Dateien: CA, Hostzertifikat, Hostschlüssel

Wer jemandem ein Nebula-Verzeichnis gibt, kopiert meist alles, einschließlich der Datei, die niemals die eigene Workstation verlassen sollte. Die Verwirrung ist verständlich, denn die drei Dateien im PKI-Block eines Hosts sehen ähnlich aus, und zwei davon sind Zertifikate. Jede beantwortet eine andere Frage, und nur zwei gehören auf den Knoten. Sortieren Sie sie nach Rolle, bevor Sie irgendetwas kopieren.

Drei Dateien, drei verschiedene Aufgaben

Das CA-Zertifikat ist ein Vertrauensanker: Es sagt einem Host, welchen Autoritäten er glauben soll, wenn ein anderer Host seine Identität vorlegt. Das Hostzertifikat ist der eigene Ausweis des Knotens, signiert von dieser Autorität. Der Hostschlüssel ist die passende private Hälfte, und er gehört genau einer Maschine. Ein Knoten mit dem CA-Zertifikat und seinem eigenen Paar kann dem Overlay beitreten und beweisen, wer er ist. Ein Knoten mit dem Schlüssel eines anderen kann sich auch als dieser andere ausgeben, und genau diesen Fehler soll diese Aufteilung verhindern.

Ein funktionierendes Hostverzeichnis auf eine zweite Maschine zu kopieren ist deshalb keine Abkürzung. Es ist eine doppelte Identität mit vorhersehbarem Ausgang.

Der Signaturschlüssel reist nie

Der CA-Signaturschlüssel ist Teil keiner Hostkonfiguration. Er prägt neue Identitäten, und wer ihn hat, kann ein Zertifikat für jede Overlay-Adresse und jede Gruppe ausstellen. Peers brauchen nur das öffentliche CA-Zertifikat, um Signaturen zu prüfen, daher hat die private Hälfte auf einem Client überhaupt keine Rolle. Bewahren Sie ihn auf der Maschine auf, auf der Zertifikate ausgestellt werden, und behandeln Sie eine versehentliche Kopie als Vorfall, nicht als Bequemlichkeit.

Wenn mehrere Personen Zertifikate ausstellen müssen, geben Sie ihnen einen Prozess statt einer Kopie des Schlüssels. Ein geteilter Signaturschlüssel auf einem Laptop ist eine Autorität, die niemand prüfen oder widerrufen kann.

Was in einem Hostzertifikat steckt

Ein Hostzertifikat bindet mehr als einen Dateinamen an einen Schlüssel. Es trägt die Overlay-Adresse des Knotens, seinen Namen und seine Gruppenzugehörigkeit, alles signiert, damit ein Peer entscheiden kann, ob er es akzeptiert. Deshalb bedeutet das Umbenennen eines Hosts, ein neues Zertifikat auszustellen, statt eine Konfigurationszeile zu bearbeiten.

nebula-cert print -path host.crt zeigt, was tatsächlich ausgestellt wurde. Lesen Sie es, bevor Sie annehmen, das Zertifikat trage die beabsichtigte Adresse.

Ein Reload reicht nicht immer

Manche PKI-Einstellungen werden per Signal neu geladen, manche nicht. Ein Zertifikat, dessen Overlay-Adresse sich geändert hat ist der klassische Fall, der einen Neustart des Prozesses statt eines Reloads erfordert.

Prüfen Sie, welche Pfade der laufende Prozess tatsächlich geöffnet hat, nicht nur welche Pfade die Konfigurationsdatei nennt. Ändern Sie dann eine Zugangsdatei, verifizieren Sie Verbindung und Logs und erst danach die nächste. Ein Reload, der erfolgreich aussieht, während das alte Zertifikat im Speicher bleibt, erzeugt eine Abweichung, die wie ein Routingproblem aussieht. Ein Neustart ist billig; das Debuggen einer Identität, die die halbe Overlay noch alt sieht, ist es nicht.

Das Entfernen einer Identität erfordert eine Sperrliste

Der Ersatz eines verlorenen oder offengelegten Ausweises hat zwei Hälften. Das neue Zertifikat stellt den Zugang wieder her, und die alte Identität muss aufhören, akzeptiert zu werden. Das sind getrennte Vorgänge, und nur den ersten auszuführen lässt den kompromittierten Ausweis gültig.

Die Sperrliste ist eine Datei, die Sie an Hosts verteilen, nicht etwas, das ein Lighthouse von sich aus verschickt. Planen Sie, wie sie jeden Knoten erreicht, auch die, die heute offline sind, und halten Sie fest, welche Fingerabdrücke Sie gesperrt haben. Rotieren Sie den Schlüssel auf der ausstellenden Maschine und bewahren Sie die Angaben des neuen Zertifikats beim Hosteintrag auf. Ein Widerruf, der nur auf der bearbeiteten Maschine existiert, ist kein Widerruf.