Android IKEv2-Vertrauensfehler: Zwischen-CA senden, keinen Root
Das Telefon weist das Gateway ab, weil die empfangene Kette zu früh endet. Entscheiden Sie: Zwischenzertifikat senden, Identität korrigieren oder Schlüsseltyp ändern.
Das Telefon verweigert die Verbindung und gibt No trusted RSA public key found for vpn.example.net aus, während dasselbe Gateway-Zertifikat von einem Laptop im selben Netz funktioniert. Der naheliegende Schritt ist, das Zertifikat neu auszustellen. Klären Sie vorher, welcher der drei Fehler vorliegt, denn nur einer betrifft den Inhalt des Zertifikats.
Drei Fehler hinter einer Meldung
Android baut eine Kette vom Gateway-Zertifikat bis zur im VPN-Profil gewählten CA und vergleicht dann den Servernamen mit dem Profil. Die Meldung berichtet das Ergebnis, nicht die Stufe. Ein Vertrauensfehler heißt, die Kette ließ sich mit den im Austausch übergebenen Zertifikaten nicht vervollständigen; ein Identitätsfehler heißt, die Kette ist gültig, aber der Name passt nicht; ein Algorithmusfehler heißt, Gerät oder Profil akzeptiert den Schlüsseltyp oder die Signatur nicht.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Entscheiden Sie mit Belegen statt durch Ausprobieren der Reihe nach. Ein Versuch auf Log-Stufe 2 am Dienst liefert Ihnen die Tabellenzeile und kostet weniger als das Neuausstellen eines Zertifikats, das nie falsch war.
Zuerst entscheiden: Kam die ganze Kette an?
strongSwan sendet das für diese Verbindung eingerichtete Zertifikat, Zwischenzertifikate sind eigene Nachweise. Sie müssen als CA-Zertifikate geladen sein, bevor der Dienst sie in eine Nutzlast setzen kann; ein Aufbau, bei dem das Serverzertifikat von einem Zwischenzertifikat signiert ist, der Root der Vertrauensanker ist und das Zwischenzertifikat nur im Build-Verzeichnis der CA liegt, erzeugt genau diesen Fehler: nur das Blatt auf der Leitung, die Kette endet früh am Telefon.
Prüfen Sie mit swanctl --list-certs in einer swanctl-Installation oder ipsec listcerts beim älteren Starter, was der Dienst hält. Das Zwischenzertifikat sollte als CA-Zertifikat mit dem Root darüber erscheinen. Fehlt es, hilft keine Client-Option; ist es da, gehen Sie zur nächsten Frage.
Prüfen Sie dann, ob es gesendet würde. Die swanctl.conf-Referenz dokumentiert send_cert: Der Standard ifasked sendet Zertifikate nur, wenn die Gegenseite gefragt hat, always sendet immer. Das alte Äquivalent ist leftsendcert=always in ipsec.conf. Die Einstellung steuert das Senden, nicht die Verfügbarkeit, und ersetzt kein Zwischenzertifikat, das der Dienst nie geladen hat.
Ist die Kette kurz, laden Sie das Zwischenzertifikat dorthin, wo der Dienst sucht
Legen Sie das Zwischenzertifikat in das CA-Verzeichnis statt neben das Blatt: /etc/ipsec.d/cacerts für einen Aufbau mit ipsec.conf, /etc/swanctl/x509ca für swanctl oder den Pfad, den Ihr Paket ersetzt. Laden Sie die Konfiguration neu und listen Sie die Zertifikate erneut. Manche Versionen senden auch ein Bündel mit der Kette in der Blattdatei, doch das CA-Verzeichnis ist die portable Anordnung über Versionen und Pakete hinweg.
Prüfen Sie auch von der Client-Seite. Das Telefon sieht nur, was der Austausch trug, also sollte das Dienstprotokoll auf Stufe 2 das Zwischenzertifikat unter den gesendeten zeigen. Zeigt das Protokoll es und scheitert das Telefon weiterhin, sind Sie in einer anderen Tabellenzeile, und Änderungen an CA-Dateien bewegen das Ergebnis nicht.
Ist die Kette vollständig, hören Sie auf, Zertifikate zu bearbeiten
Ein Identitätsfehler ist eine Abweichung zwischen dem Namen im VPN-Profil und dem Namen im Zertifikat. Android vergleicht die von Ihnen eingestellte Serveridentität mit dem Zertifikat, das es validiert hat; ein Profil, das auf eine Adresse zeigt, während das Zertifikat einen Hostnamen nennt, oder ein Profil mit einem Hostnamen, den das Zertifikat nicht abdeckt, scheitert nach erfolgreicher Kettenprüfung. Korrigieren Sie die falsche Seite und halten Sie Profil und Zertifikat deckungsgleich.
Ein Algorithmusfehler erscheint bei gültiger Kette und passendem Namen. Android-Versionen unterscheiden sich darin, welche Schlüsseltypen und Signaturverfahren sie akzeptieren, und der Profiltyp selbst begrenzt die Optionen. Nutzt das Gateway eine ältere oder ungewöhnliche Kombination, vergleichen Sie sie mit dem, was das Gerät unterstützt, bevor Sie ein defektes Zertifikat annehmen. Das Dienstprotokoll zeigt, dass der Handshake weiter kommt als im Vertrauensfall, das Signal dafür, dass die Kette nicht mehr das Problem ist.
Installieren Sie das Zwischenzertifikat nicht als Benutzer-Root auf dem Telefon
Das fehlende Zwischenzertifikat als Benutzerzertifikat auf dem Telefon zu installieren, lässt die Warnung verschwinden und ändert das Vertrauensmodell des Telefons für jede App, die benutzerinstallierte Roots akzeptiert. Es verbirgt zudem einen Auslieferungsfehler, der den nächsten Client trifft, und lässt das Gateway an jedes künftige Gerät eine unvollständige Kette senden. Die dauerhafte Reparatur liegt am Server, einmal, für alle Clients.
Halten Sie die drei Entscheidungen im Änderungsprotokoll getrennt: welche Zertifikate übertragen, welche Identität verglichen und welcher Algorithmus ausgehandelt wurde. Ein Gateway, das immer seine volle Kette sendet, ein Profil, das das Zertifikat richtig benennt, und ein Schlüsseltyp, den die Flotte unterstützt, sind drei kleine Fakten, und sie sind dieser ganze Fehler.