Wie OpenVPN Zertifikat und Schlüssel auflöst: Inline-PEM oder Pfad

Die Meldung besagt, dass OpenVPN ein Inline-Zertifikat nicht laden kann, und der Dateiname in Ihrem Kopf behauptet etwas anderes. Was der Parser erhalten hat, ist wichtiger als das, was das Dateisystem enthält, weil die Direktive cert zwei völlig verschiedene Arten von Wert annimmt. Die eine ist ein Pfad, den sie öffnet; die andere ist PEM-Text, der innerhalb der Konfiguration angekommen ist. Bis Sie wissen, welche Form der laufende Client bekommen hat, ist jede Korrektur ein Ratespiel.

Zwei Speicherformen, eine Direktive

Die Direktiven cert, key und ca akzeptieren jeweils einen Pfad oder einen Inline-Block. Wenn der Wert ein Pfad ist, öffnet OpenVPN diese Datei und liest das Objekt von der Festplatte. Wenn die Konfiguration einen durch cert-Tags begrenzten Block enthält, verbraucht dieselbe Direktive stattdessen den Inhalt zwischen diesen Tags, und es ist keine separate Datei beteiligt.

Beide Formen erzeugen am Ende dieselbe Art von Objekt, weshalb ein funktionierendes Deployment ohne weitere Änderung zwischen ihnen wechseln kann. Ein Profil, das ein eingebettetes Clientzertifikat und einen privaten Schlüssel trägt, ist selbstständig, und das Kopieren auf eine andere Maschine funktioniert, ohne auch ein Zertifikatsverzeichnis zu kopieren.

Das Umgekehrte gilt nicht. client.crt neben ein Profil zu legen, das seine eigenen Daten einbettet, ändert nichts, weil nichts in der Konfiguration auf diese Datei verweist. Das ist der mit Abstand häufigste Grund, warum eine Datei, die offensichtlich existiert, ignoriert zu werden scheint.

Wie aus einem Inline-Block ein Objekt wird

Inline-Inhalt wird aus der Konfiguration extrahiert und dem PEM-Parser als Text übergeben. Dieser Parser erwartet die üblichen Grenzen: eine BEGIN-Zeile, eine base64-Nutzlast und eine passende END-Zeile. Wurde der Block durch eine fehlgeschlagene Kopie abgeschnitten, von einer Downloadseite in HTML gehüllt oder in einem Editor geöffnet, der die Bindestriche normalisiert hat, scheitert der Parser an Inhalt, der vorhanden aussieht.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

Deshalb ist auch die Fehlerformulierung irreführend. Das Wort inline beschreibt, wo der Lader nachgesehen hat, nicht was er dort gefunden hat. Eine in einer Konfiguration genannte Datei und ein darin eingebettetes Objekt können dieselbe Beschwerde erzeugen, wenn die zugrunde liegenden Bytes unbrauchbar sind.

Prüfen Sie, welche Form das geladene Profil tatsächlich verwendet, statt welche Datei Ihr Editor zufällig geöffnet hat:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

Wie eine Pfadangabe aufgelöst wird

Ein Pfadwert wird relativ zum Arbeitsverzeichnis des Clients geöffnet, nicht relativ zu dem Verzeichnis, das die Konfiguration enthält. Unter systemd ist dieses Arbeitsverzeichnis das, was die Unit setzt, und ein interaktiver Lauf aus Ihrer Shell erbt etwas völlig anderes. Deshalb kann dieselbe Konfigurationsdatei funktionieren, wenn Sie sie von Hand testen, und als Dienst scheitern.

Relative Pfade erben dieselbe Mehrdeutigkeit. Wenn Sie einen bloßen Dateinamen sehen, fragen Sie, was das aktuelle Verzeichnis des Prozesses in der Produktion ist, statt anzunehmen, dass es Ihrem Terminal entspricht.

Für ein separat gespeichertes Zertifikat bestätigt eine Offline-Analyse das Objekt, bevor Sie irgendetwas darüber debuggen:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

Diese Befehle belegen, dass die Dateien lesbar und strukturell gültig sind. Sie belegen nicht, dass die Gegenstelle dem Aussteller vertraut, dass das Zertifikat noch innerhalb seines Gültigkeitsfensters liegt oder dass der Schlüssel dazugehört.

Was der Parserfehler Ihnen sagen kann und was nicht

Ein Parse-Fehler lokalisiert das Problem auf eine Eingabe und eine Stufe. Er sagt Ihnen nicht, welche der beiden Speicherformen der Client verwendet hat, und er sagt Ihnen nicht, ob das Objekt akzeptiert worden wäre. Das sind getrennte Fragen mit getrennten Belegen.

Sobald das Parsen gelingt, gehört der nächste Fehler zu einer späteren Stufe. Eine Vertrauensablehnung, eine Zweckabweichung oder eine Schlüsselabweichung wird von der Gegenstelle oder von der TLS-Schicht gemeldet, nicht vom Lader. Das wiederholte Ersetzen derselben Datei verschiebt diesen Fehler nicht.

Halten Sie die sensible Hälfte während der Untersuchung aus öffentlichen Berichten heraus. Teilen Sie die Direktivennamen, den Fehlertext und die Struktur des Blocks, mit entferntem Schlüsselmaterial und jeder identifizierenden Nutzlast. Das openvpn(8)-Handbuch dokumentiert beide Formen der Dateidirektiven und das Arbeitsverzeichnisverhalten dahinter.