IKEv2 hat zwei Signaturen: Zertifikat und IKE_AUTH
Die CA signiert das Zertifikat, und der Peer signiert seinen IKE_AUTH-Austausch mit einem eigenen Verfahren. Lesen Sie jede aus ihrem eigenen Feld und halten Sie beide fest.
Ihr Ticket besagt, dass das Zertifikat SHA-256 ist, während das Gateway-Log einen anderen Signaturalgorithmus nennt, und jemand hat bereits einen Antrag auf Neuausstellung der CA entworfen. Bevor dieser Antrag irgendwohin geht, trennen Sie die beiden Signaturen: die eine ist der Stempel des Ausstellers auf einem öffentlichen Schlüssel, die andere ist der Nachweis des Peers, dass er während IKE_AUTH den passenden privaten Schlüssel besitzt. Verschiedene Komponenten wählen sie, und sie dürfen sich unterscheiden. Beide dort zu lesen, wo sie leben, kostet zwei Befehle und eine Tabelle.
Lesen Sie die Signatur des Ausstellers aus dem Zertifikat
Die CA setzt ihre Signatur auf eine Bindung zwischen einer Identität und einem Schlüssel. Diese Signatur hält fest, was die CA bei der Ausstellung getan hat, nicht was das Subjekt beim Verbinden tun wird, daher beschreibt ihr Algorithmus die eigene Hash- und Schlüsselwahl der CA. Ein Subjektschlüssel des einen Typs kann unter einem CA-Schlüssel eines anderen Typs liegen, ohne dass das ein Widerspruch wäre, und eine Rotation des CA-Schlüssels ist Routine und kein Fehler. Lesen Sie beide Felder, und Sie haben die Hälfte des Inventars:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Notieren Sie beide Bezeichnungen als getrennte Einträge. Die erste beschreibt die CA, die zweite beschreibt den Schlüssel des Subjekts, und keine von beiden sagt die Online-Signatur voraus.
Lesen Sie die Online-Signatur aus dem IKE-Austausch
Während der Authentifizierung signiert jeder Peer die Austauschdaten mit seinem eigenen privaten Schlüssel, und die Gegenseite prüft diesen Nachweis gegen Identität, Vertrauenskette und Richtlinie des Zertifikats. Bei RSA gehören Padding und Hash zu diesem Online-Verfahren, ein längerer Schlüssel oder ein frisches SHA-256-Zertifikat kann also nicht von sich aus RSA-PSS für die Authentifizierungssignatur wählen. Die ausgehandelte Methode erscheint im Log des Daemons oder in seiner Verbindungsliste, nie im Zertifikat. Fragen Sie jede Seite, was sie ausgehandelt hat, denn die beiden Richtungen können sich unterscheiden.
ipsec statusall | grep -i "auth\|proposal"Wenn eine Seite ein Verfahren nennt, das die andere nicht erzeugen kann, haben Sie die Unstimmigkeit gefunden, um die es im Ticket ging. Die CA neu auszustellen ist die falsche Reparatur dafür, denn das Zertifikat war nie das, was versagt hat.
Was RFC 7427 ändert und was nicht
Die ursprünglichen Methoden sind in RFC 7296 je Algorithmuskombination nummeriert. Die spätere RFC 7427-Signaturerweiterung fügt eine allgemeine Digital Signature-Methode mit Signalisierung der Signatur-Hash-Unterstützung hinzu, sodass ein neuer Hash keine eigene Methodennummer mehr braucht. Sie wird ausgehandelt, nicht angenommen: Ein Peer gewinnt die Erweiterung nicht, weil seine Bibliothek dieselben Zertifikate parsen kann, und ein Peer, der nur die ursprünglichen Methoden implementiert, zwingt das Gateway, eine davon zu behalten. Das ist ein Richtlinienhandel mit Kompatibilitätskosten, kein Defekt.
Die Unterstützung gilt je Richtung und je Verbindung, testen Sie also den Build vor sich, statt einer Aussage auf Familienebene zu vertrauen. Eine vor drei Jahren geschriebene Fähigkeitsmatrix beschreibt drei Jahre alte Builds.
Tragen Sie vier Zeilen ins Inventar ein
Der Eintrag, der die Diskussion beendet, hat vier Zeilen, jede an einer anderen Stelle gelesen und jede von einer anderen Person geändert. Füllen Sie ihn aus, bevor Sie irgendetwas entscheiden, denn die falsche Zeile bestimmt die Reparatur.
| Objekt | Lesen aus | Geändert von |
|---|---|---|
| Signatur des Zertifikatsausstellers | Feld Signature Algorithm des Zertifikats | der CA-Betreiber, bei der Ausstellung |
| öffentlicher Schlüssel des Subjekts | Feld Public Key Algorithm des Zertifikats | wer den Subjektschlüssel erzeugt |
| IKE-Authentifizierungsverfahren | Daemon-Log oder Verbindungsliste, auth- und signature-hash-Meldung | das IKE-Profil auf beiden Peers |
| IKE- und ESP-Schutzalgorithmen | die Vorschlagsliste der Verbindung | das IPsec-Profil, je Richtung |
Jede Zeile trägt ihre eigene Kompatibilitätsfolge. Eine Änderung der ESP-Chiffre wählt nicht die Signatur des Ausstellers, und eine Lockerung der CA-Prüfung fügt keine Online-Methode hinzu, die die Peers nie ausgehandelt haben. Wenn ein Ticket eine Signaturunstimmigkeit behauptet, ist die tatsächlich falsche Zeile fast nie die erste.
Lösen Sie den Altfall, ohne die PKI zu schwächen
Ein älterer Peer bietet vielleicht nur ein Verfahren, das Ihre Richtlinie nicht mehr erlaubt. Die Wahl sind eine zeitlich begrenzte Kompatibilitätsausnahme, ein Client-Update oder eine andere Authentifizierungsregelung allein für diesen Peer. Die PKI um eine schwächere Zertifikatssignatur herum neu zu bauen behebt keine Einschränkung im Online-Austausch und schwächt jeden anderen Dienst, der derselben CA vertraut. Halten Sie fest, welche Zeile Sie geändert haben und wann die Ausnahme endet.
Führen Sie dann beide Lesungen von oben erneut aus, denn eine Änderung in einer Zeile kann verschieben, was in einer anderen ausgehandelt wird. Das ganze Inventar sind zwei Befehle und eine Tabelle, und es ist dieselbe Arbeit, ob der Peer ein Router, ein Laptop oder ein Gerät ist.