strongSwan: Schlüsseltyp, Loader und das falsche Backend

Dateiendungen benennen keine Schlüsselalgorithmen, und eine .pem-Hülle kann RSA- oder ECDSA-Material enthalten. PEM beschreibt, wie Bytes verpackt werden, während RSA und ECDSA unterschiedliche Algorithmen bezeichnen, und eine PKCS12-Datei ist wieder etwas Drittes. strongSwan lädt Anmeldedaten über Plugins und ein Konfigurations-Backend, sodass ein Zertifikat in einer Liste erscheinen kann, während der private Schlüssel nie nutzbar wird. Trennen Sie diese Schichten, bevor Sie irgendein Geheimnis bearbeiten.

Kodierung, Algorithmus und Verpackung sind drei Schichten

Eine Schlüsseldatei hat eine Kodierung, einen Algorithmus und oft einen Container. PEM ist die vertraute base64-Hülle; DER ist das binäre Gegenstück; PKCS12 bündelt ein Zertifikat mit seinem Schlüssel und seiner Kette. Eine Zertifikatsketten-Datei ist ein weiterer Container und enthält meist gar keinen privaten Schlüssel. Keine dieser Bezeichnungen sagt, ob das Material darin RSA oder ECDSA ist.

Lesen Sie den Algorithmus aus dem Objekt selbst. Ein Marketingname eines Anbieters oder eine Dateiendung ist kein Beweis, denn derselbe Aussteller kann verschiedene Schlüsseltypen ausgeben.

Vergleichen Sie öffentliche Schlüssel, bevor Sie den Loader beschuldigen

Ein Zertifikat, das lädt, beweist, dass das Zertifikat geparst wurde, nicht dass sein privater Schlüssel vorhanden oder nutzbar ist. Leiten Sie den öffentlichen Schlüssel aus dem Zertifikat und aus dem vorgeschlagenen privaten Schlüssel ab und vergleichen Sie dann die beiden Hashes. Wenn eine der Extraktionen fehlschlägt, hören Sie dort auf, denn ein Hash leerer Ausgabe beweist nichts. Übereinstimmende Hashes beweisen, dass das Paar zusammengehört, und mehr nicht darüber, ob das Zertifikat für die Aufgabe taugt.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

Der zweite Befehl berührt privates Material auf Ihrem Rechner, gibt aber nur die öffentliche Hälfte aus. Lassen Sie es dabei, und kleben Sie niemals einen privaten Schlüssel in ein Ticket. Wenn der Schlüssel verschlüsselt ist, lassen Sie das unterstützte Werkzeug nach der Passphrase fragen, statt sie auf eine Befehlszeile zu setzen, wo die Prozessliste sie offenlegen kann.

Altmodische ipsec.secrets oder swanctl-Anmeldedaten

strongSwan kennt zwei gebräuchliche Pfade für Anmeldedaten. Der alte starter-Stack liest typspezifische Einträge aus ipsec.secrets, und jeder Eintrag muss den richtigen Typ für das Material nennen. Der swanctl- und vici-Stack lädt Schlüssel aus seinem eigenen Anmeldedatenverzeichnis über seine eigene Konfiguration. Die Datei zu bearbeiten, die das laufende Backend nicht liest, ändert nichts.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Finden Sie heraus, welches Backend tatsächlich läuft, und legen Sie den Schlüssel dann dort ab, wo dieses Backend nachsieht. altmodische strongSwan-5.9-Anleitung definiert die typspezifischen Geheimnis-Einträge, und es ist keine swanctl-Dokumentation. Beides zu vermischen erzeugt einen Daemon, der eine Datei ignoriert, die der Administrator für maßgeblich hält. Ein Reload ohne Fehlermeldung bedeutet nur, dass die Konfiguration geparst wurde.

Lesen Sie das Ladeereignis und das Authentifizierungsergebnis

Lesen Sie nach einem kontrollierten Reload die eigene Ladeausgabe des Daemons für den konkreten Schlüssel. Ein in einem Statusdump aufgeführtes Zertifikat zeigt nicht, dass der private Schlüssel dazu zugeordnet wurde.

Wenn ein Client weiterhin scheitert, halten Sie Serverereignis und Clientfehler getrennt. Kettenvalidierung, Identitätsabgleich und Methodenkompatibilität sind spätere Fragen mit eigenen Belegen. Schreiben Sie das Ergebnis mit dem genauen Schlüsselpfad und dem verglichenen Hash auf, denn sonst wiederholt die nächste Schicht denselben Reload. Den CA zu ersetzen ist nicht die erste Reaktion auf eine Loader-Unstimmigkeit.