May dalawang lagda ang IKEv2: sertipiko at IKE_AUTH
Nilalagdaan ng CA ang sertipiko, at nilalagdaan ng peer ang IKE_AUTH exchange nito gamit ang sariling scheme. Basahin ang bawat isa mula sa sariling field, pagkatapos itala ang dalawa.
Sinasabi ng ticket mo na ang sertipiko ay SHA-256 habang ang log ng gateway ay may ibang algorithm ng lagda, at mayroon nang gumawa ng kahilingang muling ilabas ang CA. Bago mapunta kahit saan ang kahilingang iyon, paghiwalayin ang dalawang lagda: ang isa ay selyo ng naglabas sa pampublikong key, ang isa ay patunay ng peer na taglay nito ang katugmang pribadong key habang IKE_AUTH. Magkaibang bahagi ang pumipili sa kanila, at pinapayagang magkaiba sila. Ang pagbasa sa bawat isa mula sa kinaroroonan nito ay nangangailangan ng dalawang utos at isang talahanayan.
Basahin ang lagda ng naglabas mula sa sertipiko
Inilalagay ng CA ang lagda nito sa bigkis ng pagkakakilanlan at key. Itinatala ng lagdang iyon ang ginawa ng CA noong inilabas, hindi ang gagawin ng paksa kapag kumonekta, kaya inilalarawan ng algorithm nito ang sariling pagpili ng hash at key ng CA. Ang key ng paksang isang uri ay maaaring nasa ilalim ng key ng CA na ibang uri nang walang anumang pagkakasalungatan, at ang pag-ikot ng key ng CA ay routine at hindi depekto. Basahin ang dalawang field at mayroon ka nang kalahati ng imbentaryo:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Isulat ang dalawang label bilang magkahiwalay na entry. Inilalarawan ng una ang CA, inilalarawan ng ikalawa ang key ng paksa, at wala sa kanila ang humuhula ng online na lagda.
Basahin ang online na lagda mula sa IKE exchange
Sa panahon ng pagpapatunay, nilalagdaan ng bawat peer ang datos ng exchange gamit ang sariling pribadong key, at sinusuri ng kabilang panig ang patunay laban sa pagkakakilanlan, tanikala ng tiwala at patakaran ng sertipiko. Sa RSA, ang padding at hash ay kabilang sa online scheme na ito, kaya ang mas mahabang key o bagong SHA-256 na sertipiko ay hindi makakapili nang mag-isa ng RSA-PSS para sa lagda ng pagpapatunay. Lumilitaw ang napagkasunduang paraan sa log ng daemon o sa listahan ng koneksyon nito, hindi kailanman sa sertipiko. Itanong sa bawat panig kung ano ang napagkasunduan, dahil maaaring magkaiba ang dalawang direksyon.
ipsec statusall | grep -i "auth\|proposal"Kapag ang isang panig ay nagbanggit ng scheme na hindi magawa ng kabilang panig, natagpuan mo ang pagkakaibang tinutukoy ng ticket. Ang muling paglabas ng CA ay maling pag-aayos para doon, dahil ang sertipiko ay hindi kailanman ang nabigo.
Ano ang binabago ng RFC 7427, at ano ang hindi
Ang orihinal na mga paraan ay may bilang ayon sa kombinasyon ng algorithm sa RFC 7296. Ang RFC 7427 signature extension na sumunod ay nagdaragdag ng pangkalahatang Digital Signature method na may pagsenyas ng suporta sa signature hash, kaya ang bagong hash ay hindi na kailangan ng sariling numero ng paraan. Napagkakasunduan ito, hindi ipinapalagay: hindi nakukuha ng peer ang extension dahil kayang i-parse ng library nito ang parehong mga sertipiko, at ang peer na nagpapatupad lamang ng orihinal na mga paraan ay pinipilit ang gateway na panatilihin ang isa sa mga iyon. Iyon ay kalakalan sa patakaran na may gastos sa pagiging tugma, hindi depekto.
Ang suporta ay bawat direksyon at bawat koneksyon, kaya subukan ang build na nasa harap mo sa halip na magtiwala sa pahayag sa antas ng pamilya. Ang capability matrix na isinulat tatlong taon na ang nakalipas ay naglalarawan ng tatlong taong gulang na build.
Maglagay ng apat na hilera sa imbentaryo
Ang talaan na nagtatapos sa debate ay may apat na linya, bawat isa ay binasa mula sa ibang lugar at bawat isa ay binago ng ibang tao. Punan ito bago magpasya ng anuman, dahil ang maling hilera ang pumipili ng pag-aayos.
| Bagay | Saan ito babasahin | Sino ang nagbabago |
|---|---|---|
| lagda ng naglabas ng sertipiko | ang field na Signature Algorithm ng sertipiko | ang operator ng CA, noong inilabas |
| pampublikong key ng paksa | ang field na Public Key Algorithm ng sertipiko | sinumang gumagawa ng key ng paksa |
| scheme ng pagpapatunay ng IKE | log ng daemon o listahan ng koneksyon, abiso ng auth at signature-hash | ang profile ng IKE sa dalawang peer |
| mga algorithm ng proteksyon ng IKE at ESP | ang listahan ng panukala ng koneksyon | ang profile ng IPsec, bawat direksyon |
Bawat hilera ay may sariling bunga sa pagiging tugma. Ang pagbabago ng cipher ng ESP ay hindi pumipili ng lagda ng naglabas, at ang pagluwag ng validation ng CA ay hindi nagdaragdag ng online na paraan na hindi kailanman napagkasunduan ng mga peer. Kapag ang ticket ay nagsasabing may pagkakaiba sa lagda, ang hilerang talagang mali ay halos hindi kailanman ang una.
Lutasin ang lumang kaso nang hindi pinapahina ang PKI
Ang mas lumang peer ay maaaring mag-alok lamang ng scheme na hindi na pinapayagan ng iyong patakaran. Ang mga pagpipilian ay isang may takdang panahong pagbubukod sa pagiging tugma, isang update ng kliyente, o ibang kaayusan ng pagpapatunay para lamang sa peer na iyon. Ang muling pagtatayo ng PKI sa paligid ng mas mahinang lagda ng sertipiko ay hindi nag-aayos ng limitasyon sa online exchange at nagpapahina sa bawat ibang serbisyong nagtitiwala sa parehong CA. Itala kung aling hilera ang binago mo at kung kailan magtatapos ang pagbubukod.
Pagkatapos ay patakbuhin muli ang dalawang pagbasa mula sa itaas, dahil ang pagbabago sa isang hilera ay maaaring mag-alis sa napagkasunduan sa iba. Ang buong imbentaryo ay dalawang utos at isang talahanayan, at pareho ang trabaho maging ang peer ay router, laptop o appliance.