Android IKEv2-förtroendefel: skicka det mellanliggande CA-certifikatet, inte en rot
Telefonen avvisar gatewayen eftersom kedjan den fick slutar för tidigt. Bestäm: skicka det mellanliggande, rätta identiteten eller byt nyckeltyp.
Telefonen vägrar ansluta och skriver ut No trusted RSA public key found for vpn.example.net, medan samma gateway-certifikat fungerar från en bärbar dator i samma nätverk. Det frestande draget är att utfärda certifikatet på nytt. Innan du gör det, ta reda på vilket av tre fel du har, eftersom bara ett av dem handlar om certifikatets innehåll. Meddelandet omfattar en ofullständig kedja, en identitetsavvikelse och en nyckel eller signatur som inte stöds, och varje fel har en egen åtgärd.
Tre fel bakom ett meddelande
Android bygger en kedja från gateway-certifikatet till det CA som valts i VPN-profilen och jämför sedan servernamnet med profilen. Aviseringen rapporterar resultatet, inte steget. Ett förtroendefel betyder att kedjan inte kunde slutföras från certifikaten som levererades i utbytet; ett identitetsfel betyder att kedjan validerades men namnet inte matchade; ett algoritmfel betyder att enheten eller profilen inte accepterar nyckeltypen eller signaturen.
| 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 |
Bestäm med bevis i stället för att prova åtgärder i tur och ordning. Ett försök på loggnivå 2 mot daemonen säger vilken rad du är i, och det kostar mindre än att utfärda ett certifikat som aldrig var fel på nytt.
Bestäm först: kom hela kedjan fram?
strongSwan skickar certifikatet som är konfigurerat för den anslutningen, och mellanliggande certifikat är separata autentiseringsuppgifter. De måste laddas som CA-certifikat innan daemonen kan placera dem i en nyttolast, så en uppsättning där servercertifikatet är signerat av ett mellanliggande certifikat, roten är förtroendeankaret och det mellanliggande bara finns i CA:ns byggkatalog ger exakt detta fel: bara bladet på tråden, kedjan slutar tidigt i telefonen.
Kontrollera vad daemonen har med swanctl --list-certs i en swanctl-installation, eller ipsec listcerts med den äldre starter. Det mellanliggande ska visas som ett CA-certifikat med roten ovanför. Om det saknas hjälper ingen klientinställning; om det finns, gå vidare till nästa fråga.
Kontrollera sedan om det skulle skickas. swanctl.conf-referensen dokumenterar send_cert, vars standard ifasked bara skickar certifikat när motparten har frågat; always skickar alltid. Den äldre motsvarigheten är leftsendcert=always i ipsec.conf. Inställningen styr sändningen, inte tillgängligheten, så den kan inte kompensera för ett mellanliggande certifikat som daemonen aldrig laddade.
Om kedjan är kort, ladda det mellanliggande där daemonen letar
Lägg det mellanliggande i CA-katalogen i stället för bredvid bladet: /etc/ipsec.d/cacerts för en ipsec.conf-konfiguration, /etc/swanctl/x509ca för swanctl, eller sökvägen som ditt paket ersätter. Läs in konfigurationen igen och lista certifikaten på nytt. Vissa versioner skickar också ett paket som innehåller kedjan i bladfilen, men CA-katalogen är den flyttbara lösningen över versioner och paket.
Verifiera även från klientsidan. Telefonen ser bara det utbytet bar med sig, så daemonloggen på nivå 2 ska visa det mellanliggande bland de skickade certifikaten. Om loggen visar det och telefonen ändå misslyckas befinner du dig i en annan rad i tabellen, och fortsatt justering av CA-filer ändrar inte resultatet.
Om kedjan är komplett, sluta redigera certifikat
Ett identitetsfel är en avvikelse mellan namnet i VPN-profilen och namnet i certifikatet. Android jämför serveridentiteten du konfigurerade med certifikatet det validerade, så en profil som pekar på en adress medan certifikatet anger ett värdnamn, eller en profil som anger ett värdnamn som certifikatet inte täcker, misslyckas efter en lyckad kedjevalidering. Rätta den sida som är fel och håll profilen och certifikatet i linje när någon av dem ändras.
Ett algoritmfel uppträder med en giltig kedja och ett matchande namn. Android-versioner skiljer sig i vilka nyckeltyper och signaturscheman de accepterar, och själva profiltypen begränsar valen. Om gatewayen använder en äldre eller ovanlig kombination, jämför den med vad enheten stöder innan du antar att certifikatet är skadat. Daemonloggen visar att handskakningen fortsätter längre än i förtroendefallet, och det är signalen att kedjan inte längre är problemet.
Installera inte det mellanliggande som användarrot i telefonen
Att installera det saknade mellanliggande certifikatet som ett användarcertifikat i telefonen får varningen att försvinna och ändrar telefonens förtroendemodell för varje app som accepterar användarinstallerade rötter. Det döljer också ett leveransfel som drabbar nästa klient och låter gatewayen skicka en ofullständig kedja till varje framtida enhet. Den hållbara åtgärden är på servern, en gång, för alla klienter.
Håll de tre besluten åtskilda i ändringsloggen: vilka certifikat som skickades, vilken identitet som jämfördes och vilken algoritm som förhandlades. En gateway som alltid skickar hela sin kedja, en profil som namnger certifikatet korrekt och en nyckeltyp som flottan stöder är tre små fakta, och de utgör hela detta fel.