Android IKEv2-vertrouwensfout: stuur de tussenliggende CA, geen root
De telefoon weigert de gateway omdat de keten die hij ontving te vroeg stopt. Beslis: stuur de tussenliggende, repareer de identiteit of wijzig het sleuteltype.
De telefoon weigert verbinding te maken en drukt No trusted RSA public key found for vpn.example.net af, terwijl hetzelfde gateway-certificaat vanaf een laptop op hetzelfde netwerk werkt. De verleidelijke zet is het certificaat opnieuw uitgeven. Voordat u dat doet, bepaal welke van drie fouten u hebt, want slechts één ervan gaat over de inhoud van het certificaat. Het bericht dekt een onvolledige keten, een identiteitsverschil en een niet-ondersteunde sleutel of handtekening, en elk heeft een andere reparatie.
Drie fouten achter één bericht
Android bouwt een keten van het gateway-certificaat naar de CA die in het VPN-profiel is gekozen, en vergelijkt daarna de servernaam met het profiel. De melding rapporteert de uitkomst, niet de fase. Een vertrouwensfout betekent dat de keten niet kon worden voltooid met de certificaten die in de uitwisseling zijn geleverd; een identiteitsfout betekent dat de keten valideerde maar de naam niet overeenkwam; een algoritmefout betekent dat het apparaat of profiel het sleuteltype of de handtekening niet accepteert.
| 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 |
Beslis op basis van bewijs in plaats van reparaties op volgorde te proberen. Eén poging op logniveau 2 tegen de daemon vertelt u in welke rij u zit, en dat kost minder dan het opnieuw uitgeven van een certificaat dat nooit verkeerd was.
Beslis eerst: is de hele keten aangekomen?
strongSwan stuurt het certificaat dat voor die verbinding is geconfigureerd, en tussenliggende certificaten zijn aparte inloggegevens. Ze moeten als CA-certificaat worden geladen voordat de daemon ze in een payload kan plaatsen, dus een opzet waarbij het servercertificaat door een tussenliggende is ondertekend, de root het vertrouwensanker is en de tussenliggende alleen in de build-map van de CA staat, levert precies deze fout op: alleen het blad op de lijn, de keten eindigt vroeg op de telefoon.
Controleer wat de daemon heeft met swanctl --list-certs op een swanctl-implementatie, of ipsec listcerts met de oudere starter. De tussenliggende moet verschijnen als CA-certificaat met de root erboven. Als hij ontbreekt, helpt geen enkele clientoptie; als hij aanwezig is, ga naar de volgende vraag.
Controleer dan of hij zou worden verzonden. De swanctl.conf-referentie documenteert send_cert, waarvan de standaard ifasked certificaten alleen stuurt wanneer de peer erom heeft gevraagd; always stuurt altijd. Het oude equivalent is leftsendcert=always in ipsec.conf. Die instelling regelt het verzenden, niet de beschikbaarheid, dus kan hij een tussenliggende niet compenseren die de daemon nooit heeft geladen.
Als de keten kort is, laad de tussenliggende waar de daemon zoekt
Plaats de tussenliggende in de CA-map in plaats van naast het blad: /etc/ipsec.d/cacerts voor een ipsec.conf-opzet, /etc/swanctl/x509ca voor swanctl, of het pad dat uw pakket vervangt. Herlaad de configuratie en vermeld de certificaten opnieuw. Sommige versies sturen ook een bundel met de keten in het bladbestand, maar de CA-map is de overdraagbare regeling over versies en pakketten heen.
Verifieer ook vanaf de clientzijde. De telefoon ziet alleen wat de uitwisseling heeft gedragen, dus de daemonlog op niveau 2 moet de tussenliggende tonen in de verzonden certificaten. Als de log het toont en de telefoon nog steeds faalt, zit u in een andere rij van de tabel, en doorgaan met CA-bestanden aanpassen verandert de uitkomst niet.
Als de keten compleet is, stop met het bewerken van certificaten
Een identiteitsfout is een verschil tussen de naam in het VPN-profiel en de naam in het certificaat. Android vergelijkt de serveridentiteit die u hebt geconfigureerd met het certificaat dat het valideerde, dus een profiel dat naar een adres wijst terwijl het certificaat een hostnaam noemt, of een profiel dat een hostnaam noemt die het certificaat niet dekt, faalt na een geslaagde ketenvalidatie. Repareer de kant die fout is, en houd het profiel en het certificaat op elkaar afgestemd wanneer een van beide verandert.
Een algoritmefout verschijnt met een geldige keten en een overeenkomende naam. Android-versies verschillen in welke sleuteltypen en handtekeningsschema's ze accepteren, en het profieltype zelf beperkt de opties. Als de gateway een oudere of ongebruikelijke combinatie gebruikt, vergelijk die dan met wat het apparaat ondersteunt voordat u aanneemt dat het certificaat corrupt is. De daemonlog laat zien dat de handshake verder komt dan in het vertrouwensgeval, en dat is het signaal dat de keten niet langer het probleem is.
Installeer de tussenliggende niet als gebruiker-root op de telefoon
De ontbrekende tussenliggende als gebruikerscertificaat op de telefoon installeren laat de waarschuwing verdwijnen en verandert het vertrouwensmodel van de telefoon voor elke app die door de gebruiker geïnstalleerde roots accepteert. Het verbergt ook een leveringsfout die de volgende client zal raken, en het laat de gateway een onvolledige keten naar elk toekomstig apparaat sturen. De duurzame reparatie is op de server, één keer, voor alle clients.
Houd de drie beslissingen gescheiden in het wijzigingsrecord: welke certificaten zijn verzonden, welke identiteit is vergeleken en welk algoritme is onderhandeld. Een gateway die altijd zijn volledige keten stuurt, een profiel dat het certificaat correct benoemt, en een sleuteltype dat de vloot ondersteunt zijn drie kleine feiten, en die vormen de hele fout.