strongSwan send_cert: Wann das IKE-Zertifikat gesendet wird

Gateways protokollieren zertifikatsbezogene Authentifizierungsfehler, und der erste Reflex ist, der empfangenden Seite eine weitere CA hinzuzufügen. Das setzt voraus, dass das Zertifikat angekommen und abgelehnt worden ist. Die andere Möglichkeit ist, dass es nie gesendet wurde, und das entscheidet die Verbindungsrichtlinie des Senders. Klären Sie, welcher der beiden Fälle eingetreten ist, bevor Sie das Vertrauen ändern.

Was send_cert tatsächlich steuert

Die Zertifikatsauthentifizierung benötigt das End-Entity-Zertifikat der Gegenstelle auf der anderen Seite, entweder über den IKE-Austausch oder über eine vorherige Bereitstellung. In swanctl regelt die Verbindungseinstellung send_cert, ob dieser Endpunkt seine Zertifikatsnutzlast mitsendet: nie, immer oder ifasked. Der Standard ifasked sendet es als Antwort auf eine Zertifikatsanfrage der Gegenstelle. Das Anfordern eines Zertifikats ist eine eigene Einstellung, denn die andere Seite um ihr Zertifikat zu bitten ist nicht dasselbe wie das eigene anzubieten.

Ältere ipsec.conf-Bereitstellungen verwendeten leftsendcert und rightsendcert, und diese Namen beziehen sich auf lokale und entfernte Rollen statt direkt auf swanctl.

Erst einen Versuch lesen, dann die Verbindung ändern

Diagnostizieren Sie anhand eines einzelnen kontrollierten Versuchs, nicht anhand des allgemeinen Eindrucks, dass Zertifikate im Spiel sind. Sowohl die Richtlinie als auch die aktive Assoziation lassen sich einsehen.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

Die Verbindungsliste zeigt den konfigurierten Wert von send_cert, und die SA-Liste zeigt, welche Verbindungen tatsächlich zustande kamen. Das Protokoll ergänzt Details zur Aushandlung: ob eine Zertifikatsanfrage einging und ob eine Zertifikatsnutzlast hinausging. Ein allgemeiner Authentifizierungsfehler belegt kein Übermittlungsproblem, suchen Sie also den konkreten Austausch, bevor Sie etwas schlussfolgern. Notieren Sie den Zeitstempel des Versuchs, damit das Protokollfenster den gesamten Handshake abdeckt.

Das Vertrauen der Empfängerseite ist eine eigene Entscheidung

Übermittlung und Vertrauen sind verschiedene Eigenschaften, und das eine zu beheben behebt das andere nicht. Eine empfangende Seite muss den vorgesehenen Vertrauensanker besitzen, eine nutzbare Kette erhalten und die erwartete Identität der Gegenstelle erfüllen. Ein End-Entity-Zertifikat, das ohne sein Zwischenzertifikat eintrifft, scheitert weiterhin an einer strengen Kettenprüfung. Umgekehrt zwingt das Installieren einer CA eine Gegenstelle keineswegs, ihr Zertifikat überhaupt zu senden.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

Die Prüfung zeigt, welcher Aussteller das Zertifikat signiert hat und wann es abläuft, und dem muss der Anker der Empfängerseite entsprechen. Vertrauen Sie der ausstellenden CA, die die Bereitstellung besitzt, nicht jedem Zwischenzertifikat der Kette, denn jedes Zwischenzertifikat zur Wurzel zu erheben erweitert das Vertrauen weit über eine Gegenstelle hinaus. Lassen Sie die Identitätsprüfung aktiv, denn eine Verbindung, die nur mit deaktivierter Validierung zustande kommt, ist keine Lösung. Wo die Kette unvollständig ist, reparieren Sie die Bereitstellung statt die Richtlinie des Senders.

Den Sender nur mit Belegen ändern

Wenn das Protokoll zeigt, dass das Zertifikat nie gesendet wurde und die Empfängerseite eines angefordert hat, ist send_cert auf always für diese Verbindung eine begründete Änderung. Setzen Sie sie in der swanctl-Konfiguration um, laden Sie die Verbindungen neu und bauen Sie eine neue Sitzung auf, statt die bestehende SA weiterzuverwenden. Bestätigen Sie, dass die Zertifikatsnutzlast nun erscheint und die Empfängerseite sie gegen den vorgesehenen Anker akzeptiert. Ändert sich nichts, lag der Fehler doch auf der Vertrauensseite und die Sendereinstellung war nicht die Ursache.

Schreiben Sie den beobachteten Austausch, den Anker und die daraus folgende Verifikation in den Änderungseintrag. Eine Zertifikatskorrektur, die sich nicht so beschreiben lässt, ist ein Zufall.