IKEv2-Zertifikat und SAN: Warum die Identitätsprüfung scheitert

Ihr Zertifikat führt zu einer vertrauenswürdigen CA, die Daten stimmen, und trotzdem verweigert der Peer den Abschluss von Phase 1 mit einem Identitätsfehler. Erreichbarkeit und eine gültige Signatur sind nur die Hälfte dessen, was ein IKEv2-Client prüft. Die andere Hälfte ist, ob die erwartete Identität im richtigen Feld des Zertifikats steht, und diese Erwartung setzt das Profil, nicht der Dateiname des Zertifikats.

Das Symptom hat immer dieselbe Form

Ein Verbindungsprofil wird von einem Hostnamen auf eine IP-Adresse umgestellt oder von einem Zertifikat mit DNS-Namen auf eines erneuert, das nur Adressen trägt, und der Tunnel verhandelt nicht mehr. Am Netzwerkpfad hat sich nichts geändert. Der Client erreicht den Peer, erhält ein Zertifikat und weist die Peer-Identität zurück, weil die erwartete Kennung nicht in einem Feld steht, das er akzeptiert. Erneuerungen sind der übliche Auslöser, da das Ersatzzertifikat oft aus einer anderen Vorlage stammt als das ersetzte.

Beide Seiten protokollieren dann etwas Unbrauchbares, weshalb der Fehler meist als Zertifikatsproblem gemeldet wird. Das Client-Protokoll nennt vielleicht die gewünschte Identität, und dieser Name ist der Hinweis, den Sie brauchen, nicht das Ablaufdatum.

Gleichen Sie den Kennungstyp ab, nicht nur den Wert

Ein dNSName-SAN und ein iPAddress-SAN sind verschiedene Felder mit verschiedenen Übereinstimmungsregeln, daher erfüllt ein Zertifikat, das 203.0.113.10 als DNS-Zeichenkette trägt, keinen Client, der eine IP-Identität erwartet. Moderne Validatoren ignorieren den Common Name weitgehend, sodass die freundliche Bezeichnung in den Zertifikatsdetails nichts darüber beweist, was passen wird. Wurde ein Hostname bei der Fehlersuche durch eine Adresse ersetzt, gehen Sie davon aus, dass die erwartete Identität mitgewandert ist, bis Sie es geprüft haben. Vergleichen Sie die Zeichenkette im Profil mit der im SAN Zeichen für Zeichen, denn ein Punkt am Ende oder ein überflüssiges Leerzeichen genügt.

Platzhalter sind eine Annehmlichkeit nur für DNS und folgen eigenen Übereinstimmungsregeln, ein weiterer Grund, warum sich ein IP-basiertes Profil nie auf sie verlassen sollte.

Finden Sie, wo jeder Client die Erwartung speichert

In strongSwan stammt der mit dem Zertifikat verglichene Wert aus der Peer-Identitätseinstellung: rightid in der klassischen Konfiguration oder die id eines Abschnitts für entfernte Verbindungen in swanctl. Die Dokumentation zur Apple-IKEv2-Interoperabilität ist hier nützlich, weil sie die Identitätskonventionen darlegt, die ein profilgesteuerter Client verwendet, und diese Konventionen erklären eine Klasse von Abweichungen, die im Netz zufällig wirken.

Apple-Konfigurationsprofile enthalten ein Feld für die entfernte Kennung, und der Wert dort ist das, was der Client prüft, nicht die Serveradresse in den Verbindungseinstellungen. Windows- und Appliance-Clients haben jeweils ihr eigenes Feld mit eigenem Standardwert, und der Standard folgt oft der Adresse, die Sie eingegeben haben. Wenn zwei Felder nicht übereinstimmen, gewinnt das, was der Client tatsächlich liest, und das ist selten das, was Sie bearbeitet haben.

Reparieren Sie das Profil oder das Zertifikat bewusst

Prüfen Sie das Peer-Zertifikat mit zugelassenen Werkzeugen und listen Sie die SAN-Einträge mit ihren Typen auf, bevor Sie etwas ändern. Diese Prüfung braucht keinen privaten Schlüssel und keinen Upload und klärt die Frage in Sekunden. Wenn die Bereitstellung eine DNS-Identität vorsieht, muss das Zertifikat sie als dNSName-Eintrag tragen, und wenn sie eine Adresse vorsieht, braucht das Zertifikat einen iPAddress-Eintrag für genau diese Adresse.

Ist das Zertifikat falsch, fordern Sie beim Betreiber ein korrigiertes mit der konkreten erwarteten Kennung an. Ist das Profil falsch, korrigieren Sie das Profil und lassen Sie das Zertifikat unverändert. Das Abschalten der Identitätsprüfung lässt den Fehler verschwinden und entfernt die Prüfung, dass der Tunnel mit dem beabsichtigten Peer spricht.

Dokumentieren Sie die erwartete Identität je Client-Plattform, denn ein Wert, den ein Client automatisch ableitet, muss auf einem anderen möglicherweise ausdrücklich angegeben werden.

Geben Sie der Erneuerungsanfrage vier Fakten

Notieren Sie die erwartete Kennung und ihren Typ, die SAN-Einträge, die das aktuelle Zertifikat tatsächlich hat, den prüfenden Client samt Version und den genauen Fehlertext. Eine Erneuerungsanfrage aus diesen vier Zeilen erhält gleich beim ersten Mal das richtige Zertifikat statt eines weiteren mit demselben vertrauten Dateinamen.