Den OpenVPN-CA-Signaturschlüssel aus /etc/openvpn heraushalten
Der CA-Arbeitsbereich stellt Identitäten aus; der Dienst verbraucht nur bereitgestelltes Material. Geben Sie jeder Rolle ein eigenes Konto, Verzeichnis und Backup und prüfen Sie beides.
Zwei Verzeichnisse, die in einem Tutorial gleich aussehen, erfüllen völlig unterschiedliche Aufgaben. Das eine enthält die Zertifizierungsstelle: ihren privaten Schlüssel, ihren Seriennummernzähler und die Aufzeichnung über alles, was sie signiert hat. Das andere enthält, was der Daemon zum Starten und Bedienen von Clients braucht. Beide auf demselben Host unter demselben Konto abzulegen ist für einen Nachmittag bequem und für den Rest der Lebensdauer der Bereitstellung teuer, denn der Daemon läuft dann neben dem einen Schlüssel, der jede gewünschte Identität erzeugen kann.
Was der CA-Arbeitsbereich enthält
Ein PKI-Verzeichnis ist Ausstellerzustand, nicht Konfiguration. Es enthält den privaten Schlüssel und das Zertifikat der CA, eine Seriennummerndatei, einen Index der ausgestellten Zertifikate und das pro Identität erzeugte Material.
Das Signieren einer Anfrage ändert diesen Zustand, weshalb der Arbeitsbereich einem administrativ verwalteten Konto auf einem Host gehört, auf dem der VPN-Dienst nicht läuft. Wer den privaten Schlüssel der CA lesen kann, kann ein Zertifikat ausstellen, dem der Server vertraut; der Schutz des Schlüssels ist also das gesamte Vertrauensmodell in einer Datei. Ihn an einen zweiten Ort zu kopieren, um einen Schritt zu sparen, schafft ein zweites Ding, das geschützt werden muss, und ein zweites, das vergessen werden kann. Jede Signatur erhöht außerdem die Seriennummer und hängt einen Eintrag an den Index an, weshalb der Arbeitsbereich eine Kopie von Zustand ist und kein Ordner mit Dateien.
Das öffentliche CA-Zertifikat ist anders. Es ist zur Verteilung gedacht, und Clients und Server verwenden es, um sich gegenseitig zu verifizieren.
Was der Daemon beim Start liest
Ein laufender Server verbraucht einen kleinen Satz: sein eigenes Zertifikat, seinen eigenen privaten Schlüssel, das CA-Zertifikat zur Prüfung der Peers und welches Schlüsselmaterial sein gewählter Modus auch erfordert. Er liest diese Pfade beim Start und erneut beim Neuladen.
Eigentum muss gegen die Einheit bewertet werden, die tatsächlich startet, nicht gegen eine interaktive Root-Shell. Deklariertes Sandboxing kann einen Teil des Dateisystems schreibgeschützt oder unsichtbar machen, selbst wenn ein manueller Test als Root gelingt.
systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?Die dritte Zeile ist die, die Leute überspringen. Sie fragt das eigene Konto des Daemons, ob es den Schlüssel lesen kann, und das ist die einzige Version der Frage, die zählt, sobald Privilegien abgegeben wurden. Ein Null-Exit als Root sagt nichts darüber aus, was nach der Abgabe geschieht.
Die beiden Fehlerpfade sollten getrennt werden, bevor Sie irgendeine Berechtigung ändern. Ein Signaturfehler weist auf das PKI-Verzeichnis, die Suchberechtigung auf dessen übergeordneten Verzeichnissen und das Konto, das den Aussteller ausführt. Ein Startfehler weist auf die Einheit, ihr Arbeitsverzeichnis und die in der Serverkonfiguration genannten Pfade. Den ganzen Baum für alle lesbar zu machen, behebt keines von beiden und entfernt die Grenze, auf der beide beruhen.
Warum das Kopieren des CA-Schlüssels auf den Server später scheitert
Die Kopie beginnt meist als Debugging-Schritt: Jemand möchte einen Client auf dem VPN-Host erneuern, also landet der CA-Schlüssel in /etc/openvpn und die Erneuerung funktioniert. Die unmittelbare Aufgabe gelingt, und die Grenze ist weg.
Dann wird der Server gesichert, und die Signaturinstanz kommt in die Backups. Ein Snapshot, ein Support-Bundle oder eine Kopie des Konfigurationsverzeichnisses trägt nun die Fähigkeit, vertrauenswürdige Identitäten auszustellen, solange die CA gültig ist. Wer diese Kopie besitzt, kann ein Zertifikat für jeden Namen erzeugen, den der Server akzeptiert, auch für Namen, die nie ausgestellt wurden. Die einzige Aufzeichnung dieser Ausstellung ist die, die man zu behalten beschließt.
Die Erholung aus diesem Zustand ist keine Frage des Löschens einer Datei. Sie müssen entscheiden, ob der Schlüssel offengelegt wurde, die CA rotieren, falls ja, und das Vertrauen an jeden Peer neu verteilen. Ein getrennter Arbeitsbereich erspart das ganze Gespräch.
Konten, Verzeichnisse, Backups
Geben Sie dem Aussteller ein eigenes Konto und Heimatverzeichnis, vom VPN-Host ferngehalten, wo das praktikabel ist. Geben Sie dem Daemon ein anderes Konto mit Lesezugriff auf das bereitgestellte Material und Schreibzugriff auf nichts, was Zertifikate ausstellt. Stellen Sie bereit, indem Sie öffentliche Zertifikate nach außen kopieren und niemals privaten Ausstellerzustand nach innen ziehen. Sichern Sie die beiden Rollen getrennt, weil ihre Sensibilität und ihre Wiederherstellungsgeschichten sich unterscheiden.
Aktualisieren Sie nach einem Widerruf die CRL-Datei, die die Serverkonfiguration nennt, und laden Sie dann den Dienst neu, damit neue Verbindungen sie lesen. Die Easy-RSA-Dokumentation behandelt den Aufbau des Arbeitsbereichs und den Signaturablauf; die Eigentumsregeln darum bleiben eine Entscheidung über Ihren Host. Prüfen Sie, was der Dienst geladen hat, mit openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate statt anzunehmen, dass das Neuladen sie übernommen hat.
Ein Test, der die Trennung beweist
Prüfen Sie den Negativfall, nicht nur den funktionierenden. Signieren Sie ein Zertifikat vom Ausstellerkonto wie vorgesehen und bestätigen Sie dann, dass dasselbe Konto den Dienst nicht starten und den privaten Schlüssel des Servers nicht lesen kann. Bestätigen Sie dann, dass das Konto des Daemons den privaten Schlüssel der CA nicht lesen kann.
Diese drei Prüfungen dauern ein paar Minuten und überstehen Personalwechsel, weil sie Aussagen über Berechtigungen sind und nicht über Gewohnheit. Schreiben Sie das Ergebnis mit den abgedeckten Pfaden und Konten sowie dem Datum der Durchführung auf. Die nächste Person, die diese Bereitstellung übernimmt, leitet die Grenze sonst erneut aus einem Tutorial ab, das nie eine hatte. Ein datierter Eintrag ist auch das, was die nächste Überprüfung Minuten statt eines Nachmittags dauern lässt.