Telefon keeldub ühendumast ja trükib No trusted RSA public key found for vpn.example.net, samas kui sama lüüsi sertifikaat töötab samas võrgus sülearvutist. Kiusatus on sertifikaat uuesti välja anda. Enne seda tehke kindlaks, milline kolmest tõrkest teil on, sest ainult üks puudutab sertifikaadi sisu.

Kolm tõrget ühe teate taga

Android ehitab ahela lüüsi sertifikaadist VPN-profiilis valitud CA-ni ja võrdleb seejärel serveri nime profiiliga. Teade teatab tulemuse, mitte etapi. Usaldustõrge tähendab, et ahelat ei saanud vahetuses antud sertifikaatidega lõpule viia; identiteeditõrge, et ahel on kehtiv, kuid nimi ei klapi; algoritmitõrge, et seade või profiil ei võta vastu võtmetüüpi ega allkirja.

What you seeWhat it points toFirst move
Chain stops after the leaf in the daemon logintermediate not loaded or not sentload the intermediate as CA material
Chain validates, name differs from the profileidentity mismatchfix the profile name or the certificate SAN
Chain validates, handshake still failskey or signature not acceptedcompare key type against the device

Otsustage tõendite põhjal, mitte proovides parandusi järjest. Üks katse logitasemel 2 deemonil ütleb, millises reas olete, ja see maksab vähem kui sertifikaadi uuesti väljaandmine, mis polnud kunagi vale.

Otsustage esmalt: kas jõudis kohale terve ahel?

strongSwan saadab selle ühenduse jaoks seadistatud sertifikaadi ja vahesertifikaadid on eraldi volitused. Need tuleb laadida CA-sertifikaatidena enne, kui deemon saab need koormasse panna, seega paigutus, kus serveri sertifikaat on allkirjastatud vahega, juur on usalduse ankru ja vahe elab ainult CA koostekataloogis, annab täpselt selle tõrke: juhtmel on ainult leht ja ahel lõpeb telefonis vara.

Kontrollige, mida deemon hoiab, käsuga swanctl --list-certs swanctl-paigaldises või ipsec listcerts vanema starteriga. Vahe peaks ilmuma CA-sertifikaadina, juur selle kohal. Kui see puudub, ei aita ükski kliendi valik; kui see on olemas, minge järgmise küsimuse juurde.

Seejärel kontrollige, kas see saadetaks. swanctl.conf viide dokumenteerib send_cert, mille vaikeväärtus ifasked saadab sertifikaate ainult siis, kui partner on küsinud, samas kui always saadab alati. Vana vaste on leftsendcert=always failis ipsec.conf. See säte juhib saatmist, mitte kättesaadavust, seega ei korva vahesertifikaati, mida deemon kunagi ei laadinud.

Kui ahel on lühike, laadige vahe sinna, kus deemon otsib

Pange vahe CA kataloogi, mitte lehe kõrvale: /etc/ipsec.d/cacerts paigutusele ipsec.conf, /etc/swanctl/x509ca swanctlile või tee, mille teie pakett asendab. Laadige seadistus uuesti ja loetlege sertifikaadid uuesti. Mõned versioonid saadavad ka kimbu, mis sisaldab ahelat lehefaili sees, kuid CA kataloog on kaasaskantav lahendus versioonide ja pakettide vahel.

Kontrollige ka kliendi poolelt. Telefon näeb ainult seda, mida vahetus kandis, seega peaks deemoni logi tasemel 2 näitama vahesertifikaati saadetud sertifikaatide hulgas. Kui logi näitab seda ja telefon ikka nurjub, olete tabeli teises reas ning CA-failide muutmine tulemust ei muuda.

Kui ahel on täielik, lõpetage sertifikaatide muutmine

Identiteeditõrge on lahknevus VPN-profiili nime ja sertifikaadi nime vahel. Android võrdleb teie seadistatud serveri identiteeti sertifikaadiga, mida see valideeris, seega profiil, mis osutab aadressile, samal ajal kui sertifikaat nimetab hostinime, või profiil hostinimega, mida sertifikaat ei kata, nurjub pärast edukat ahela valideerimist. Parandage vale pool ja hoidke profiil ning sertifikaat kooskõlas.

Algoritmitõrge ilmneb kehtiva ahela ja sobiva nimega. Androidi versioonid erinevad selle poolest, milliseid võtmetüüpe ja allkirjaskeeme need aktsepteerivad, ja profiili tüüp ise piirab valikuid. Kui lüüs kasutab vanemat või ebatavalist kombinatsiooni, võrrelge seda seadme toetatuga enne, kui eeldate sertifikaadi riket. Deemoni logi näitab, et käepigistus jõuab kaugemale kui usalduse korral, mis on märk, et ahel pole enam probleem.

Ärge paigaldage vahesertifikaati telefonis kasutaja juurena

Puuduva vahe paigaldamine kasutajasertifikaadina telefonis kaotab hoiatuse ja muudab telefoni usaldusmudelit iga rakenduse jaoks, mis aktsepteerib kasutaja paigaldatud juuri. See varjab ka tarnevea, mis tabab järgmist klienti, ja jätab lüüsi saatma puudulikku ahelat igale tulevasele seadmele. Kestev parandus on serveris, üks kord, kõigi klientide jaoks.

Hoidke kolm otsust muudatuste logis eraldi: millised sertifikaadid edastati, millist identiteeti võrreldi ja milline algoritm kokku lepiti. Lüüs, mis saadab alati oma täieliku ahela, profiil, mis nimetab sertifikaadi õigesti, ja võtmetüüp, mida park toetab, on kolm väikest fakti ja need on kogu see tõrge.

Seotud artiklid