SAN ng sertipiko ng IKEv2: bakit nabigo ang pagsusuri ng pagkakakilanlan

Ang iyong sertipiko ay nakakadena sa isang pinagkakatiwalaang CA, maayos ang mga petsa, at tumatanggi pa rin ang peer na tapusin ang phase 1 na may error sa pagkakakilanlan. Ang maabot at valid na lagda ay kalahati lamang ng sinusuri ng isang kliyente ng IKEv2. Ang kabilang kalahati ay kung lumilitaw ang inaasahang pagkakakilanlan sa sertipiko sa tamang field, at ang inaasahang iyon ay itinatakda ng profile, hindi ng filename ng sertipiko.

Palaging pareho ang hugis ng sintomas

Ang profile ng koneksyon ay binabago mula sa hostname patungo sa IP address, o binabago mula sa sertipikong may DNS name patungo sa isang may mga address lamang, athumihinto ang tunnel sa pakikipagnegosasyon. Walang nagbago sa landas ng network. Naabot ng kliyente ang peer, tumatanggap ng sertipiko, at tinatanggihan ang pagkakakilanlan ng peer dahil ang identifier na sinabihang asahan ay hindi kinakatawan sa isang field na tinatanggap nito. Ang mga pag-renew ang karaniwang dahilan, dahil ang kapalit na sertipiko ay madalas nagmumula sa ibang template kaysa sa pinapalitan nito.

Pagkatapos ay nag-log ang magkabilang panig ng isang bagay na walang silbi, kaya ang kabiguan ay karaniwang iniuulat bilang problema sa sertipiko. Maaaring pangalanan ng log ng kliyente ang gustong pagkakakilanlan, at ang pangalang iyon ang clue na kailangan mo, hindi ang petsa ng pag-expire.

Itugma ang uri ng identifier, hindi lamang ang halaga

Ang SAN na dNSName at SAN na iPAddress ay magkaibang field na may magkaibang tuntunin sa pagtutugma, kaya ang sertipikong nagdadala ng 203.0.113.10 bilang DNS string ay hindi nakakasiya sa kliyenteng umaasa ng pagkakakilanlang IP. Karamihan sa mga modernong validator ay binabalewala ang common name, kaya ang palakaibigang label sa mga detalye ng sertipiko ay walang pinapatunayan tungkol sa kung ano ang tutugma. Kung ang hostname ay pinalitan ng address habang nagte-troubleshoot, ipagpalagay na lumipat kasama nito ang inaasahang pagkakakilanlan hanggang suriin mo. Ihambing ang string sa profile sa string sa SAN nang titik-titik, dahil sapat na ang isang tuldok sa dulo o isang sobrang espasyo.

Ang mga wildcard ay kaginhawahan lamang ng DNS at sumusunod sa sarili nilang mga tuntunin sa pagtutugma, na isa pang dahilan kung bakit ang profile na nakabatay sa IP ay hindi dapat kailanman umasa sa mga ito.

Alamin kung saan iniimbak ng bawat kliyente ang inaasahan

Sa strongSwan, ang halagang inihahambing sa sertipiko ay nagmumula sa setting ng pagkakakilanlan ng peer: rightid sa klasikong configuration, o ang id ng isang seksyon ng remote connection sa swanctl. Ang dokumentasyon nito tungkol sa interoperability ng Apple IKEv2 ay kapaki-pakinabang dito dahil ipinapaliwanag nito ang mga kombensiyon ng pagkakakilanlan na ginagamit ng kliyenteng pinapatakbo ng profile, at ipinapaliwanag ng mga kombensiyong iyon ang isang uri ng hindi pagtutugma na mukhang random sa wire.

Ang mga configuration profile ng Apple ay may field ng remote identifier, at ang halaga doon ang sinusuri ng kliyente, hindi ang address ng server sa mga setting ng koneksyon. Ang mga kliyente ng Windows at appliance ay may kani-kaniyang field na may kani-kaniyang default, at ang default ay madalas sumusunod sa address na tinype mo. Kapag hindi nagkasundo ang dalawang field, ang pinakabinabasa talaga ng kliyente ang nananalo, at bihirang ito ang na-edit mo.

Ayusin ang profile o ang sertipiko, nang sinasadya

Bago baguhin ang anuman, siyasatin ang sertipiko ng peer gamit ang mga aprubadong tool at ilista ang mga entry ng SAN kasama ang kanilang mga uri. Ang pagsisiyasat na iyon ay hindi nangangailangan ng pribadong key at upload, at nilulutas ang tanong sa ilang segundo. Kung ang deployment ay nagnanais ng isang pagkakakilanlang DNS, dapat itong dalhin ng sertipiko bilang entry na dNSName, at kung ang deployment ay nagnanais ng isang address, kailangan ng sertipiko ng entry na iPAddress para sa eksaktong address na iyon.

Kapag mali ang sertipiko, humingi sa operator ng naitama na may partikular na inaasahang identifier. Kapag mali ang profile, ayusin ang profile at iwanan ang sertipiko. Ang pag-disable ng validation ng pagkakakilanlan ay nagpapawala ng error at nag-aalis ng pagsusuring ang tunnel ay kausap ang peer na nilayon mo.

Idokumento ang inaasahang pagkakakilanlan para sa bawat platform ng kliyente, dahil ang halagang awtomatikong hinango ng isang kliyente ay maaaring kailanganing tahasang nakasaad sa iba.

Bigyan ang kahilingan sa pag-renew ng apat na katotohanan

Isulat ang inaasahang identifier at ang uri nito, ang mga entry ng SAN na talagang mayroon ang kasalukuyang sertipiko, ang kliyente at bersyon na gumagawa ng pagsusuri, at ang eksaktong teksto ng error. Ang kahilingan sa pag-renew na binuo mula sa apat na linyang ito ay nakakakuha ng tamang sertipiko sa unang pagkakataon, sa halip na isa pang may parehong pamilyar na filename.