Android IKEv2 bizalmi hiba: a köztes CA-t küldje, ne a gyökeret

A telefon megtagadja a kapcsolódást, és No trusted RSA public key found for vpn.example.net üzenetet ír ki, miközben ugyanaz az átjáró-tanúsítvány működik egy laptopról ugyanazon a hálózaton. A csábító lépés a tanúsítvány újrakibocsátása. Előbb állapítsa meg, melyik a három hiba közül, mert csak az egyik szól a tanúsítvány tartalmáról.

Három hiba egy üzenet mögött

Az Android láncot épít az átjáró tanúsítványától a VPN-profilban kiválasztott CA-ig, majd összeveti a kiszolgáló nevét a profillal. Az értesítés az eredményt közli, nem a szakaszt. A bizalmi hiba azt jelenti, hogy a lánc nem volt befejezhető a cserében átadott tanúsítványokkal; az identitáshiba, hogy a lánc érvényes, de a név nem egyezik; az algoritmushiba, hogy az eszköz vagy a profil nem fogadja el a kulcstípust vagy az aláírást.

Bizonyítékok alapján döntsön, ne próbálja ki a javításokat sorrendben. Egyetlen próba 2-es naplózási szinten a daemonon megmondja, melyik sorban van, és kevesebbe kerül, mint egy soha nem hibás tanúsítvány újrakibocsátása.

Először döntse el: megérkezett a teljes lánc?

A strongSwan az adott kapcsolathoz beállított tanúsítványt küldi, a köztes tanúsítványok pedig külön hitelesítő adatok. CA-tanúsítványként kell betölteni őket, mielőtt a daemon a hasznos teherbe teheti őket, ezért az az elrendezés, amelyben a kiszolgáló tanúsítványát köztes írja alá, a gyökér a bizalmi horgony, és a köztes csak a CA build-könyvtárában él, pontosan ezt a hibát adja: csak a levél van a vezetéken, és a lánc korán véget ér a telefonon.

Ellenőrizze, mi van a daemonnál a swanctl --list-certs paranccsal swanctl-telepítésnél, vagy a ipsec listcerts paranccsal a régebbi starterrel. A köztesnek CA-tanúsítványként kell megjelennie, felette a gyökérrel. Ha hiányzik, semmilyen kliensbeállítás nem segít; ha ott van, lépjen a következő kérdésre.

Utána ellenőrizze, elküldené-e. A swanctl.conf-leírás dokumentálja a send_cert beállítást, amelynek alapértéke ifasked csak akkor küld tanúsítványokat, ha a partner kérte, míg a always mindig küld. A régi megfelelő a leftsendcert=always a ipsec.conf fájlban. A beállítás a küldést szabályozza, nem az elérhetőséget, ezért nem pótolja azt a köztes tanúsítványt, amelyet a daemon soha nem töltött be.

Ha a lánc rövid, töltse be a közteset ott, ahol a daemon keresi

Tegye a közteset a CA-könyvtárba, ne a levél mellé: /etc/ipsec.d/cacerts a ipsec.conf szerinti elrendezéshez, /etc/swanctl/x509ca a swanctlhez, vagy arra az útra, amelyet a csomagja helyettesít. Töltse újra a konfigurációt, és listázza ismét a tanúsítványokat. Egyes verziók köteget is küldenek a lánccal a levélfájlban, de a CA-könyvtár a hordozható elrendezés verziók és csomagok között.

Ellenőrizze a kliens oldaláról is. A telefon csak azt látja, amit a csere szállított, ezért a 2-es szintű daemonnaplónak mutatnia kell a közteset a küldött tanúsítványok között. Ha mutatja, és a telefon mégis meghiúsul, a táblázat másik sorában van, és a CA-fájlok módosítása nem változtat az eredményen.

Ha a lánc teljes, hagyja abba a tanúsítványok szerkesztését

Az identitáshiba a VPN-profil neve és a tanúsítvány neve közötti eltérés. Az Android összeveti a beállított kiszolgáló-identitást azzal a tanúsítvánnyal, amelyet érvényesített, ezért a címre mutató profil, miközben a tanúsítvány gépnevet nevez meg, vagy az a profil, amelynek gépnevét a tanúsítvány nem fedi, sikeres láncérvényesítés után is meghiúsul. Javítsa a hibás oldalt, és tartsa összhangban a profilt és a tanúsítványt.

Az algoritmushiba érvényes lánccal és egyező névvel jelenik meg. Az Android-verziók eltérnek abban, milyen kulcstípusokat és aláírási sémákat fogadnak el, és a profiltípus maga korlátozza a lehetőségeket. Ha az átjáró régebbi vagy szokatlan kombinációt használ, hasonlítsa össze azzal, amit az eszköz támogat, mielőtt a tanúsítvány sérülését feltételezné. A napló megmutatja, hogy a kézfogás tovább jut, mint a bizalmi esetben, ez a jele annak, hogy a lánc már nem a probléma.

Ne telepítse a közteset felhasználói gyökérként a telefonra

A hiányzó köztes felhasználói tanúsítványként telepítése a telefonra eltünteti a figyelmeztetést, és megváltoztatja a telefon bizalmi modelljét minden olyan alkalmazás számára, amely elfogadja a felhasználó által telepített gyökereket. Elrejti a következő klienst sújtó szállítási hibát is, és az átjárót minden jövőbeli eszköznek hiányos láncot küldve hagyja. A tartós javítás a kiszolgálón van, egyszer, minden kliensnek.

Tartsa a három döntést külön a változásnaplóban: mely tanúsítványok kerültek átadásra, mely identitás lett összevetve, és mely algoritmusban állapodtak meg. Az átjáró, amely mindig a teljes láncát küldi, a profil, amely helyesen nevezi meg a tanúsítványt, és a flotta által támogatott kulcstípus három apró tény, és ez a teljes hiba.