Android IKEv2-tillitsfeil: send den mellomliggjande CA-en, ikkje ei rot
Telefonen avviser gatewayen fordi kjeda han fekk, stoppar for tidleg. Bestem: send den mellomliggjande, rett identiteten eller endre nøkkeltypen.
Telefonen nektar å kopla til og skriv ut No trusted RSA public key found for vpn.example.net, medan det same gateway-sertifikatet fungerer frå ein berbar PC på same nettverket. Det freistande trekket er å gje ut sertifikatet på nytt. Før du gjer det, finn ut kva for ein av tre feil du har, fordi berre ein av dei handlar om innhaldet i sertifikatet. Meldinga dekkjer ei ufullstendig kjede, eit identitetsavvik og ein nøkkel eller signatur som ikkje blir støtta, og kvar har ei ulik reparasjon.
Tre feil bak éi melding
Android byggjer ei kjede frå gateway-sertifikatet til CA-en som er vald i VPN-profilen, og samanliknar deretter servernamnet med profilen. Varselet rapporterer resultatet, ikkje trinnet. Ein tillitsfeil tyder at kjeda ikkje kunne fullførast frå sertifikata som vart leverte i utvekslinga; ein identitetsfeil tyder at kjeda vart validert, men namnet stemde ikkje; ein algoritmefeil tyder at eininga eller profilen ikkje godtar nøkkeltypen 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 |
Bestem ut frå prov i staden for å prøve reparasjonar i rekkjefølgje. Eitt forsøk på loggnivå 2 mot daemonen fortel kva rad du er i, og det kostar mindre enn å gje ut eit sertifikat som aldri var feil på nytt.
Bestem først: kom heile kjeda fram?
strongSwan sender sertifikatet som er konfigurert for den tilkoplinga, og mellomliggjande sertifikat er separate legitimasjonar. Dei må lastast inn som CA-sertifikat før daemonen kan plassere dei i ein nyttelast, så eit oppsett der server sertifikatet er signert av ein mellomliggjande, rota er tillitsankeret, og den mellomliggjande berre ligg i byggjekatalogen til CA-en, gjev nøyaktig denne feilen: berre bladet på tråden, kjeda som sluttar tidleg på telefonen.
Sjekk kva daemonen har med swanctl --list-certs på ein swanctl-installasjon, eller ipsec listcerts med den eldre starteren. Den mellomliggjande skal visast som eit CA-sertifikat med rota over seg. Viss han manglar, hjelper inga klientinnstilling; viss han finst, gå vidare til neste spørsmål.
Sjekk deretter om han ville bli send. swanctl.conf-referansen dokumenterer send_cert, der standarden ifasked berre sender sertifikat når motparten har spurt; always sender uansett. Den eldre ekvivalenten er leftsendcert=always i ipsec.conf. Den innstillinga styrer sending, ikkje tilgjenge, så ho kan ikkje kompensere for ein mellomliggjande som daemonen aldri lasta.
Viss kjeda er kort, last den mellomliggjande der daemonen leitar
Legg den mellomliggjande i CA-katalogen i staden for ved sida av bladet: /etc/ipsec.d/cacerts for eit ipsec.conf-oppsett, /etc/swanctl/x509ca for swanctl, eller stien pakken din erstattar. Last konfigurasjonen på nytt og list sertifikata igjen. Nokre versjonar sender òg ein bunt som inneheld kjeda i bladfila, men CA-katalogen er den flyttbare ordninga på tvers av versjonar og pakkar.
Verifiser òg frå klientsida. Telefonen ser berre det utvekslinga bar med seg, så daemonloggen på nivå 2 skal vise den mellomliggjande blant sertifikata som blir sende. Viss loggen viser han og telefonen framleis feilar, er du i ei anna rad i tabellen, og å halde fram med å justere CA-filer vil ikkje endre resultatet.
Viss kjeda er komplett, slutt å redigere sertifikat
Ein identitetsfeil er eit avvik mellom namnet i VPN-profilen og namnet i sertifikatet. Android samanliknar serveridentiteten du konfigurerte, med sertifikatet det validerte, så ein profil som peikar på ei adresse medan sertifikatet namngjev eit vertsnamn, eller ein profil som namngjev eit vertsnamn sertifikatet ikkje dekkjer, feilar etter vellykka kjedevalidering. Rett den sida som er feil, og hald profilen og sertifikatet i samsvar når ein av dei endrar seg.
Ein algoritmefeil viser seg med ei gyldig kjede og eit samsvarande namn. Android-versjonar er ulike i kva nøkkeltypar og signaturskjema dei godtar, og profiltypen sjølv avgrensar vala. Viss gatewayen brukar ein eldre eller uvanleg kombinasjon, samanlikn han med det eininga støttar før du trur sertifikatet er øydelagt. Daemonloggen vil vise at handtrykket går lenger enn i tillitstilfellet, og det er signalet om at kjeda ikkje lenger er problemet.
Ikkje installer den mellomliggjande som brukarrot på telefonen
Å installere den manglande mellomliggjande som eit brukarsertifikat på telefonen fjernar åtvaringa og endrar tillitsmodellen til telefonen for kvar app som godtar brukarinstallerte røter. Det skjuler òg ein leveringsfeil som vil råke neste klient, og lèt gatewayen sende ei ufullstendig kjede til kvar framtidig eining. Den varige reparasjonen er på serveren, éin gong, for alle klientar.
Hald dei tre avgjerdene åtskilde i endringsloggen: kva sertifikat som vart sende, kva identitet som vart samanlikna, og kva algoritme som vart forhandla. Ein gateway som alltid sender heile kjeda si, ein profil som namngjev sertifikatet rett, og ein nøkkeltype flåten støttar er tre små fakta, og dei er heile denne feilen.