Easy-RSA meldet fehlende PKI? Es schaut woanders nach

Der Befehl bricht mit einer fehlenden ca.crt oder einer fehlenden index.txt ab, dabei stellt die CA seit Monaten Zertifikate aus. An der Autorität hat sich nichts geändert; der Befehl hat einfach woanders nachgesehen. Easy-RSA 3 ermittelt ein PKI-Verzeichnis aus einer Option, einer Umgebungsvariablen, einer vars-Datei und einem eingebauten Standardwert, und jede dieser Quellen kann von der Autorität der Installation wegzeigen. Prüfen Sie, welche gewonnen hat, bevor Sie etwas anlegen.

Der Fehler nennt eine Datei, kein Verzeichnis

Das Installationsverzeichnis und das Ausstellerverzeichnis sind zwei verschiedene Orte. Findet man easyrsa auf dem Rechner, beweist das nur, dass das Werkzeug installiert ist, nicht dass es die Autorität gefunden hat, der Ihr VPN vertraut.

Deshalb wirkt eine Neuinstallation des Pakets oder ein erneuter Init-Schritt produktiv und ändert doch nichts.

Prüfen Sie zuerst den Selektor

In Easy-RSA 3 ist der Selektor EASYRSA_PKI oder die passende --pki-dir-Option. Geben Sie einen absoluten Pfad wie --pki-dir=/srv/pki/office an, und die Antwort hängt nicht mehr davon ab, wo Sie gerade standen. Diese eine Gewohnheit beseitigt eine ganze Klasse dieses Fehlers, besonders bei Skripten aus cron oder aus einem CI-Checkout.

Bestätigen Sie zuerst die Generation, denn die Easy-RSA 2-Gewohnheit einer vars-Datei plus build-key ist ein anderes Modell als das, welches Easy-RSA 3 erwartet. easyrsa --version gibt die Generation aus, bevor es irgendetwas anderes tut, und ./easyrsa --help listet die Unterbefehle auf: ein build-key-Ziel bedeutet 2.x, während build-client-full für 3.x steht. Einen alten KEY_DIR-Pfad in einen 3.x-Aufruf mitzunehmen, weil der Verzeichnisname vertraut aussieht, erzeugt genau diesen Fehler.

Wenn Versionszeichenfolge und Befehlssyntax nicht zusammenpassen, halten Sie an und lesen Sie die Dokumentation der installierten Version.

Die Rangfolge erklärt eine vars-Datei, die verlor

Die dokumentierte Rangfolge ist Befehlszeilenoption, dann Umgebung, dann vars-Datei, dann eingebauter Standardwert. Ein korrekter Wert in vars verliert daher gegen eine geerbte Umgebungsvariable, und das ist die stille Variante dieses Fehlers. Prüfen Sie die beabsichtigten Variablen und die Dateiauswahl, statt die gesamte Umgebung in ein Ticket zu kippen. Der Unterschied zwischen beiden ist meist ein Geheimnis.

Gehen Sie die Kette der Reihe nach durch und notieren Sie, welche Quelle den Pfad geliefert hat, den der Befehl verwendet hat. Sobald Sie das wissen, ist die Lösung ein Flag oder ein Export statt einer neuen Zertifizierungsstelle.

Die Easy-RSA-Konfigurationsreferenz definiert den Selektor und die Rangfolge und ist die Quelle, die ins Ticket gehört.

Bestätigen Sie den Aussteller mit öffentlichem Material

Lesen Sie beim üblichen dateibasierten Aussteller ca.crt und vergleichen Sie den Fingerabdruck mit dem Ausstellerdatensatz, den Sie freigegeben haben. Ein passender Subject-Name ist kein Identitätsnachweis, und ein Verzeichnis mit dem Namen production ist es ebenso wenig. Nur der Fingerabdruck verbindet die gefundene Datei mit der Autorität, der Ihre Peers vertrauen sollten.

Eine Nur-Lese-Prüfung genügt: openssl x509 -in /srv/pki/office/ca.crt -noout -subject -issuer -serial -fingerprint -sha256.

Klären Sie dann die Rolle des Verzeichnisses. Ein Anforderungsverzeichnis, das ein Client nutzt, ist keine Ausstellerdatenbank, und ein offline gehaltener Signaturschlüssel hat auf keinem VPN-Host etwas zu suchen. Ein fehlendes ca.key ist in diesem Aufbau eine Designeigenschaft, keine Erlaubnis, eine Ersatzautorität zu erfinden.

Wenn der Zustand wirklich weg ist

Manchmal stimmt der Pfad und der Zustand ist wirklich nicht da. Eine leere index.txt und ein neu gestarteter Serienzähler ergeben eine PKI, die gesund aussieht und nichts über die Zertifikate beweisen kann, die sie nie gesehen hat: Erneuerungen widerrufen die alten nicht, und die neuen Nummern kollidieren mit der Historie. Stellen Sie stattdessen aus der freigegebenen Sicherung der CA wieder her, denn eine leere PKI anderswo zu initialisieren verschiebt nur den Fehler und hinterlässt eine zweite, unabhängige Autorität.

Wenn Pfad und Aussteller übereinstimmen, behandeln Sie den nächsten Fehler sachlich. Permission denied, ein Signaturschlüssel, der seine Passphrase braucht, und ein fehlender Ausstellungsdatensatz sind drei verschiedene Störungen, und nur eine davon betrifft das Verzeichnis, das Sie gerade korrigiert haben.

Entfernen Sie niemals die Schlüsselverschlüsselung und erweitern Sie keine Verzeichnisrechte, um einen Pfadfehler zu überdecken. Der Fehler ist billig zu beheben; die Reparatur nicht.