Chyba důvěry IKEv2 na Androidu: pošlete zprostředkující CA, ne kořenový

Telefon odmítá připojení a vypisuje No trusted RSA public key found for vpn.example.net, zatímco stejný certifikát brány funguje z notebooku ve stejné síti. Lákavým krokem je certifikát znovu vydat. Nejdřív ale zjistěte, kterou ze tří poruch máte, protože jen jedna se týká obsahu certifikátu.

Tři poruchy za jednou zprávou

Android sestaví řetěz od certifikátu brány k CA zvolené v profilu VPN a pak porovná jméno serveru s profilem. Oznámení hlásí výsledek, ne fázi. Porucha důvěry znamená, že řetěz nešlo dokončit s certifikáty předanými ve výměně; porucha identity, že řetěz je platný, ale jméno nesedí; porucha algoritmu, že zařízení nebo profil nepřijímá typ klíče či podpis.

Rozhodujte podle důkazů, ne zkoušením oprav popořadě. Jeden pokus na úrovni protokolu 2 na daemonu vám řekne, ve kterém řádku jste, a stojí méně než nové vydání certifikátu, který nikdy nebyl špatný.

Nejdřív rozhodněte: dorazil celý řetěz?

strongSwan posílá certifikát připravený pro toto spojení a zprostředkující certifikáty jsou samostatné údaje. Musí se načíst jako CA certifikáty, než je daemon může vložit do nákladu, takže uspořádání, kde je certifikát serveru podepsán zprostředkujícím, kořen je kotvou důvěry a zprostředkující žije jen v adresáři sestavení CA, dává přesně tuto poruchu: na drátu je jen list a řetěz na telefonu končí brzy.

Zkontrolujte, co daemon drží, pomocí swanctl --list-certs v nasazení swanctl, nebo ipsec listcerts se starším starterem. Zprostředkující se má objevit jako CA certifikát s kořenem nad ním. Chybí-li, žádná volba klienta nepomůže; je-li přítomen, přejděte k další otázce.

Pak ověřte, zda by se poslal. Reference swanctl.conf popisuje send_cert, jehož výchozí ifasked posílá certifikáty jen tehdy, když protějšek požádal, zatímco always posílá vždy. Starší ekvivalent je leftsendcert=always v ipsec.conf. Nastavení řídí odesílání, ne dostupnost, takže nenahradí zprostředkující certifikát, který daemon nikdy nenačetl.

Je-li řetěz krátký, načtěte zprostředkující tam, kde ho daemon hledá

Umístěte zprostředkující do adresáře CA, ne vedle listu: /etc/ipsec.d/cacerts pro uspořádání s ipsec.conf, /etc/swanctl/x509ca pro swanctl, nebo cestu, kterou nahrazuje váš balíček. Znovu načtěte konfiguraci a certifikáty znovu vypište. Některé verze posílají i svazek s řetězem uvnitř souboru listu, ale adresář CA je přenosné uspořádání mezi verzemi a balíčky.

Ověřte to i ze strany klienta. Telefon vidí jen to, co výměna přenesla, takže protokol daemonu na úrovni 2 má ukázat zprostředkující mezi odeslanými certifikáty. Ukazuje-li ho a telefon přesto selhává, jste v jiném řádku tabulky a úpravy souborů CA výsledek nezmění.

Je-li řetěz úplný, přestaňte certifikáty upravovat

Porucha identity je nesoulad mezi jménem v profilu VPN a jménem v certifikátu. Android porovnává identitu serveru, kterou jste nastavili, s certifikátem, který ověřil, takže profil ukazující na adresu, zatímco certifikát uvádí jméno hostitele, nebo profil se jménem hostitele, které certifikát nepokrývá, selže po úspěšném ověření řetězu. Opravte špatnou stranu a držte profil i certifikát v souladu, když se jedna strana změní.

Porucha algoritmu se objeví s platným řetězem a shodným jménem. Verze Androidu se liší v tom, které typy klíčů a schémata podpisu přijímají, a samotný typ profilu omezuje možnosti. Používá-li brána starší nebo neobvyklou kombinaci, porovnejte ji s tím, co zařízení podporuje, než budete předpokládat, že je certifikát poškozený. Protokol daemonu ukáže, že handshake postoupí dál než v případě důvěry, což je signál, že řetěz už není problém.

Neinstalujte zprostředkující jako uživatelský kořen v telefonu

Instalace chybějícího zprostředkujícího jako uživatelského certifikátu v telefonu odstraní varování a změní model důvěry telefonu pro každou aplikaci, která přijímá uživatelsky nainstalované kořeny. Také skryje chybu doručení, která zasáhne dalšího klienta, a nechá bránu posílat neúplný řetěz každému budoucímu zařízení. Trvalá oprava je na serveru, jednou, pro všechny klienty.

Držte tři rozhodnutí odděleně v záznamu změn: které certifikáty byly přeneseny, která identita porovnána a který algoritmus vyjednán. Brána, která vždy posílá celý řetěz, profil, který certifikát správně pojmenuje, a typ klíče, který flotila podporuje, jsou tři malá fakta a tvoří celou tuto poruchu.