Napaka zaupanja Android IKEv2: pošljite vmesni CA, ne korenskega
Telefon zavrne prehod, ker se prejeta veriga konča prezgodaj. Odločite se: poslati vmesni, popraviti identiteto ali spremeniti vrsto ključa.
Telefon noče vzpostaviti povezave in izpiše No trusted RSA public key found for vpn.example.net, medtem ko isti certifikat prehoda deluje s prenosnika v istem omrežju. Mamljiva poteza je ponovna izdaja certifikata. Preden to storite, ugotovite, katera od treh okvar je pri vas, saj se le ena nanaša na vsebino certifikata. Sporočilo zajema nepopolno verigo, neujemanje identitete in nepodprt ključ ali podpis, vsaka pa ima drugačno popravilo.
Tri okvare za enim sporočilom
Android sestavi verigo od certifikata prehoda do CA, izbrane v profilu VPN, nato primerja ime strežnika s profilom. Obvestilo poroča o izidu, ne o stopnji. Okvara zaupanja pomeni, da verige ni bilo mogoče dokončati iz certifikatov, dostavljenih v izmenjavi; okvara identitete pomeni, da je bila veriga potrjena, a se ime ni ujemalo; okvara algoritma pomeni, da naprava ali profil ne sprejema vrste ključa ali podpisa.
| 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 |
Odločajte se na podlagi dokazov, namesto da popravila preizkušate po vrsti. En poskus na ravni dnevnika 2 proti demonskemu procesu vam pove, v kateri vrstici ste, in stane manj kot ponovna izdaja certifikata, ki nikoli ni bil napačen.
Najprej se odločite: ali je prispela cela veriga?
strongSwan pošlje certifikat, nastavljen za to povezavo, vmesni certifikati pa so ločene poverilnice. Naloženi morajo biti kot certifikati CA, preden jih demonski proces lahko vstavi v koristni tovor, zato postavitev, kjer je strežniški certifikat podpisan z vmesnim, koren je sidro zaupanja, vmesni pa obstaja le v gradbeni mapi CA, povzroči natanko to okvaro: na žici samo list, veriga se na telefonu konča zgodaj.
Preverite, kaj ima demonski proces, s swanctl --list-certs v namestitvi swanctl ali ipsec listcerts s starejšim starterjem. Vmesni bi se moral prikazati kot certifikat CA s korenom nad njim. Če ga ni, nobena možnost odjemalca ne pomaga; če je prisoten, pojdite na naslednje vprašanje.
Nato preverite, ali bi bil poslan. Referenca swanctl.conf dokumentira send_cert, katerega privzeta vrednost ifasked pošlje certifikate le, ko je druga stran zahtevala; always pošlje vedno. Starejši ustreznik je leftsendcert=always v ipsec.conf. Ta nastavitev nadzoruje pošiljanje, ne razpoložljivosti, zato ne more nadomestiti vmesnega certifikata, ki ga demonski proces ni nikoli naložil.
Če je veriga kratka, naložite vmesni certifikat tja, kjer išče demonski proces
Vmesni certifikat postavite v mapo CA, ne ob list: /etc/ipsec.d/cacerts za nastavitev ipsec.conf, /etc/swanctl/x509ca za swanctl, ali pot, ki jo nadomesti vaš paket. Znova naložite konfiguracijo in znova izpišite certifikate. Nekatere različice pošljejo tudi sveženj, ki vsebuje verigo v datoteki lista, vendar je mapa CA prenosljiva ureditev med različicami in paketi.
Preverite tudi na strani odjemalca. Telefon vidi le, kar je prinesla izmenjava, zato mora dnevnik demonskega procesa na ravni 2 prikazati vmesni certifikat med poslanimi certifikati. Če ga dnevnik prikaže, telefon pa še vedno ne uspe, ste v drugi vrstici tabele, in nadaljnje prilagajanje datotek CA izida ne bo spremenilo.
Če je veriga popolna, prenehajte urejati certifikate
Okvara identitete je neujemanje med imenom v profilu VPN in imenom v certifikatu. Android primerja konfigurirano identiteto strežnika s certifikatom, ki ga je potrdil, zato profil, ki kaže na naslov, medtem ko certifikat navaja ime gostitelja, ali profil, ki navaja ime gostitelja, ki ga certifikat ne pokriva, spodleti po uspešnem preverjanju verige. Popravite napačno stran in ohranite profil ter certifikat usklajena, ko se kateri od njiju spremeni.
Okvara algoritma se pojavi z veljavno verigo in ujemajočim se imenom. Različice Androida se razlikujejo po tem, katere vrste ključev in podpisnih shem sprejemajo, in sam tip profila omejuje možnosti. Če prehod uporablja starejšo ali neobičajno kombinacijo, jo primerjajte s tem, kar naprava podpira, preden domnevate, da je certifikat poškodovan. Dnevnik demonskega procesa bo pokazal, da rokovanje napreduje dlje kot v primeru zaupanja, in to je znak, da veriga ni več težava.
Vmesnega certifikata ne nameščajte kot uporabniški koren na telefonu
Namestitev manjkajočega vmesnega certifikata kot uporabniškega certifikata na telefonu odpravi opozorilo in spremeni model zaupanja telefona za vsako aplikacijo, ki sprejema uporabniško nameščene korene. Prav tako skrije napako pri dostavi, ki bo prizadela naslednjega odjemalca, in pusti prehod, da vsaki prihodnji napravi pošilja nepopolno verigo. Trajno popravilo je na strežniku, enkrat, za vse odjemalce.
V zapisu sprememb imejte tri odločitve ločene: kateri certifikati so bili poslani, katera identiteta je bila primerjana in kateri algoritem je bil dogovorjen. Prehod, ki vedno pošlje svojo celotno verigo, profil, ki pravilno poimenuje certifikat, in vrsta ključa, ki jo flota podpira, so tri majhna dejstva, in sestavljajo celotno to okvaro.