Mac IKEv2 ECDSA: aling uri ng sertipiko ang para sa kliyente?

Sa macOS, ang pagpili ng ECDSA sa isang setting ng kliyente ng IKEv2 ay sumasagot sa makitid na tanong: aling sertipiko ang nagpapatunay ng pagkakakilanlan ng Mac. Hindi nito inilalarawan ang sertipiko ng gateway, ang lagda na naglabas ng sertipiko ng kliyente, o ang panukala sa pag-encrypt para sa tunel. Ang ituring ang apat na papel na ito bilang isang tanong ng pagiging tugma ay siyang dahilan kung bakit ang tamang lokal na setting ay napagbibintangan ng hindi pagtutugma sa panig ng server. Maliit ang desisyon, ngunit ang ebidensiyang ginagamit para dito ay dapat tumpak.

Isang sertipiko ang pinangalanan ng field na ito: ang lokal na pagkakakilanlan

Ang Network Extension API ng Apple ay naglalantad ng uri ng sertipiko para sa kredensiyal ng kliyente, kabilang ang NEVPNIKEv2CertificateType.ECDSA256, na dokumentado bilang uri ng sertipikong ECDSA p-256. Naaangkop ang property sa sertipikong ibinigay sa pamamagitan ng identityReference o identityData.

Ibig sabihin, ang desisyon ay tungkol sa sertipikong ipinapakita ng Mac, kasama ang pribadong susi na kasama nito. Piliin ang uri na tumutugma sa pampublikong susi ng dahon ng sertipikong iyon at ibigay ang pagkakakilanlan sa sinusuportahang mekanismo. Kung walang magamit na pribadong susi ang Mac para sa pagkakakilanlan, hindi maililigtas ng pagpili ng uri ang koneksiyon.

Ang mga pinamamahalaang profile ay gumagawa ng parehong desisyon sa pamamagitan ng CertificateType ng payload ng IKEv2, kasama ang isang sanggunian ng sertipiko tulad ng PayloadCertificateUUID. May mga paunang kundisyon at schema ang mga field na iyon para sa target na bersyon ng OS; ang hubad na halaga ng uri na kinopya sa isang profile ay hindi mai-install, at maaaring hindi ilantad ng window ng mga setting ang bawat opsiyon ng API. Suriin ang mga paunang kundisyon ng payload para sa bersyong iyon bago ang paglalagay.

Magpasya ayon sa papel, hindi sa label ng sertipiko

Basahin ang field na babaguhin mo at itanong kung aling sertipiko ang tinutukoy nito. Hinahalo ng mga label sa tagatingin ng sertipiko ang paksa, tagapaglabas at algorithm ng lagda, at isa lamang sa mga ito ang kabilang sa pagpili ng pagkakakilanlan ng kliyente.

Kung ang tagatingin ng sertipiko ay nagpapakita ng lagda ng ECDSA mula sa CA, inilalarawan nito ang susi sa paglagda ng tagapaglabas. Ang sariling susi ng kliyente ay maaaring RSA pa rin, at ang field ng uri ay dapat sumunod sa susi ng kliyente, hindi sa linya ng lagda. Ang nag-iisang pagkalito na ito ay nagpapaliwanag sa maraming ulat na "naka-configure ang ECDSA ngunit nabibigo ang koneksiyon". Ihambing ang uri ng susi sa dahon sa uri na pinili sa profile bago baguhin ang anuman.

Nagiging mas simple ang desisyon kapag natukoy na ang dahon: ECDSA256 para sa susi ng kliyenteng p-256, isa pang sinusuportahang uri para sa ibang susi. Kung hindi tugma ang sertipiko ng kliyente at ang susi nito, ayusin ang pares na iyon bago baguhin ang profile ng VPN.

Ang sertipiko ng gateway ay hiwalay na desisyon

Ipinapakita ng gateway ang sarili nitong sertipiko at binibigyang-katwiran ng Mac ito laban sa anchor ng pagtitiwala at inaasahang pangalan. Kung gumagamit ang sertipikong iyon ng ECDSA, RSA o ibang uri ng susi, ito ay katangian ng server, hindi ng setting ng pagkakakilanlan ng kliyente.

Ang lokal na suporta para sa sertipiko ng kliyenteng ECDSA ay hindi nagpapatunay na ang bawat sertipiko ng gateway, kurba o configuration ng pagpapatotoo ng server ay magtutulungan. Suriin ang pagkakakilanlan ng server, ang kadena nito at ang paraan ng pagpapatotoo ng IKE bilang hiwalay na input, at subukan sa profile na talagang ilalagay.

Kung ang sertipiko ng gateway ang problema, karaniwang lumilitaw ang sintomas sa pagpapatunay ng kapares, hindi sa pagpili ng pagkakakilanlan. Basahin ang yugto ng pagpalya bago baguhin ang uri ng kliyente, dahil hindi pareho ang lunas sa pagpalya ng pagtitiwala at sa hindi pagtutugma ng susi ng kliyente.

Ang lagda ng tagapaglabas at ang pangkat ng kasunduan sa susi ay hindi uri ng kliyente

Itinatago ng X.509 ang pampublikong susi ng paksa at ang lagda ng tagapaglabas sa magkaibang field. Inilalarawan ng impormasyon ng pampublikong susi ng paksa ang susi sa sertipiko; inilalarawan ng algorithm ng lagda ang susi ng CA at ang operasyon ng paglagda. Ang una lamang ang tumutugma sa setting ng uri ng sertipiko.

Ang mga panukala ng IKE at Child SA ay isa pang aksis. Ang uri ng sertipikong ECDSA ay hindi pagpili ng pag-encrypt ng ESP, at ang pagbabago ng pangkat ng kasunduan sa susi ay hindi pumipili ng uri ng sertipiko. Maaaring may wastong panukala ang isang profile ngunit maling uri ng pagkakakilanlan, o tamang uri ng pagkakakilanlan ngunit panukalang tinatanggihan ng kapares.

Panatilihing hiwalay ang tatlong linya sa talaan ng pagbabago: sertipiko at susi ng pagkakakilanlan, mga input ng pagtitiwala ng gateway, at mga algorithm ng panukala. Ang pagsasama-sama ng mga ito sa isang tala na "mga setting ng crypto" ay nagpapahirap na iugnay ang susunod na pagpalya.

I-verify ang desisyon sa mga field na na-configure mo

Suriin ang pagkakakilanlang aktwal na tinutukoy ng profile, pagkatapos ay tiyakin na ang sertipiko sa sangguniang iyon ay may inaasahang pampublikong susi at magamit na pribadong susi. Dapat magtugma ang uring ipinapakita sa UI, ang sinangguniang sertipiko at ang susi sa device.

Susunod, tiyakin ang mga input ng gateway: ang inaasahang pangalan ng server, ang anchor ng pagtitiwala at ang paraan ng pagpapatotoo ng IKE. Sa huli, kumonekta at basahin kung saan humihinto ang handshake. Ang pagpalya bago ang pagpapalitan ng pagkakakilanlan ay tumuturo palayo sa setting na ito; ang pagpalya sa pagpapatunay ng kapares ay tumuturo sa panig ng gateway.

Itala ang piniling uri, ang sanggunian ng pagkakakilanlan at ang paksa ng sertipiko ng gateway sa mga tala ng paglalagay. Maaaring baguhin ng susunod na update ng profile ang alinman sa mga ito, at mas mabilis ihambing ang tatlong pinangalanang halaga kaysa sa screenshot ng panel ng mga setting.