Error sa tiwala ng Android IKEv2: ipadala ang intermediate CA, hindi root
Tinatanggihan ng telepono ang gateway dahil masyadong maaga ang pagtatapos ng natanggap na chain. Magpasya: ipadala ang intermediate, ayusin ang identity, o palitan ang uri ng key.
Tumangging kumonekta ang telepono at nagpi-print ng No trusted RSA public key found for vpn.example.net, habang gumagana ang parehong certificate ng gateway mula sa laptop sa parehong network. Ang nakakaakit na hakbang ay muling mag-isyu ng certificate. Bago gawin iyon, alamin kung alin sa tatlong pagpalya ang nasa iyo, dahil isa lang sa kanila ang tungkol sa nilalaman ng certificate. Sinasaklaw ng mensahe ang hindi kumpletong chain, hindi pagtutugma ng identity, at hindi suportadong key o lagda, at bawat isa ay may ibang pag-aayos.
Tatlong pagpalya sa likod ng isang mensahe
Bumubuo ang Android ng chain mula sa certificate ng gateway hanggang sa CA na pinili sa profile ng VPN, pagkatapos ay inihahambing ang pangalan ng server sa profile. Ang notification ay nag-uulat ng resulta, hindi ng yugto. Ang pagpalya sa tiwala ay nangangahulugang hindi makumpleto ang chain mula sa mga certificate na inihatid sa palitan; ang pagpalya sa identity ay nangangahulugang na-validate ang chain ngunit hindi tumugma ang pangalan; ang pagpalya sa algorithm ay nangangahulugang hindi tinatanggap ng device o profile ang uri ng key o lagda.
| 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 |
Magpasya gamit ang ebidensya sa halip na subukan ang mga pag-aayos nang sunud-sunod. Isang pagsubok sa antas ng log 2 laban sa daemon ay nagsasabi kung aling hilera ka, at mas mababa ang gastos kaysa sa muling pag-isyu ng certificate na hindi kailanman naging mali.
Magpasya muna: dumating ba ang buong chain?
Ipinapadala ng strongSwan ang certificate na naka-configure para sa koneksyong iyon, at ang mga intermediate ay hiwalay na kredensyal. Kailangan silang i-load bilang CA certificate bago mailagay ng daemon sa payload, kaya ang layout kung saan ang certificate ng server ay pinirmahan ng intermediate, ang root ang trust anchor, at ang intermediate ay nasa build directory lang ng CA ay gumagawa ng eksaktong pagpalyang ito: leaf lang sa wire, maagang nagtatapos ang chain sa telepono.
Tingnan kung ano ang hawak ng daemon gamit ang swanctl --list-certs sa deployment ng swanctl, o ipsec listcerts sa mas lumang starter. Dapat lumitaw ang intermediate bilang CA certificate na may root sa itaas nito. Kung wala ito, walang opsyon sa client ang makakatulong; kung naroon ito, pumunta sa susunod na tanong.
Pagkatapos ay tingnan kung ipapadala ito. Dokumentado ng reference ng swanctl.conf ang send_cert, na ang default na ifasked ay nagpapadala ng certificate lamang kapag humiling ang peer; ang always ay nagpapadala anuman. Ang legacy na katumbas ay leftsendcert=always sa ipsec.conf. Kinokontrol ng setting na iyon ang pagpapadala, hindi ang pagiging available, kaya hindi nito mababayaran ang intermediate na hindi kailanman na-load ng daemon.
Kung maikli ang chain, i-load ang intermediate kung saan naghahanap ang daemon
Ilagay ang intermediate sa directory ng CA at hindi sa tabi ng leaf: /etc/ipsec.d/cacerts para sa setup na ipsec.conf, /etc/swanctl/x509ca para sa swanctl, o ang path na pinapalitan ng iyong package. I-reload ang configuration at ilista muli ang mga certificate. Ang ilang bersyon ay nagpapadala rin ng bundle na naglalaman ng chain sa loob ng leaf file, ngunit ang directory ng CA ang portableng kaayusan sa mga bersyon at package.
I-verify din mula sa panig ng client. Nakikita lang ng telepono ang dinala ng palitan, kaya dapat ipakita ng log ng daemon sa antas 2 ang intermediate sa mga ipinadalang certificate. Kung ipinapakita ito ng log at nabigo pa rin ang telepono, nasa ibang hilera ka ng talahanayan, at ang patuloy na pag-adjust ng mga CA file ay hindi magbabago ng resulta.
Kung kumpleto ang chain, itigil ang pag-edit ng mga certificate
Ang pagpalya sa identity ay hindi pagtutugma sa pagitan ng pangalan sa profile ng VPN at ng pangalan sa certificate. Inihahambing ng Android ang identity ng server na na-configure mo sa certificate na na-validate nito, kaya ang profile na tumuturo sa isang address habang ang certificate ay nagpapangalan ng hostname, o ang profile na nagpapangalan ng hostname na hindi saklaw ng certificate, ay nabigo pagkatapos ng matagumpay na validation ng chain. Ayusin ang maling panig, at panatilihing pantugma ang profile at certificate kapag nagbago ang alinman.
Ang pagpalya sa algorithm ay lumilitaw na may valid na chain at tugmang pangalan. Nagkakaiba ang mga release ng Android sa kung aling uri ng key at scheme ng lagda ang tinatanggap nila, at nililimitahan ng uri ng profile mismo ang mga opsyon. Kung gumagamit ang gateway ng mas luma o kakaibang kombinasyon, ihambing ito sa sinusuportahan ng device bago ipagpalagay na sira ang certificate. Ipapakita ng log ng daemon na mas malayo ang pag-usad ng handshake kaysa sa kaso ng tiwala, at iyon ang senyales na hindi na ang chain ang problema.
Huwag i-install ang intermediate bilang user root sa telepono
Ang pag-install ng nawawalang intermediate bilang user certificate sa telepono ay nagpapawala ng babala at nagbabago ng modelo ng tiwala ng telepono para sa bawat app na tumatanggap ng user-installed na root. Nagtatago rin ito ng bug sa delivery na tatama sa susunod na client, at iniiwan ang gateway na nagpapadala ng hindi kumpletong chain sa bawat hinaharap na device. Ang matibay na pag-aayos ay sa server, isang beses, para sa lahat ng client.
Panatilihing hiwalay ang tatlong desisyon sa record ng pagbabago: aling mga certificate ang ipinadala, aling identity ang inihambing, at aling algorithm ang napagkasunduan. Ang gateway na laging nagpapadala ng buong chain, ang profile na wastong nagpapangalan ng certificate, at ang uri ng key na sinusuportahan ng fleet ay tatlong maliliit na katotohanan, at sila ang buong pagpalyang ito.