Magdagdag ng VPN client nang hindi ginagawang muli ang CA

Kailangan mo ng isa pang sertipiko para sa isa pang laptop, ngunit ang unang tutorial sa mga resulta ng paghahanap ay nagsisimula sa isang utos na nagbubura ng PKI directory. Ang utos na iyon ay para sa unang setup, hindi sa pagpapatala, at ang pagpapatakbo nito ay kumukuha sa iyo ng CA, kasaysayan ng pag-isyu at bawat profile ng kliyente na nagtiwala sa lumang issuer. Mas makitid ang desisyon: mayroon pa bang magagamit na estado ang issuer, at umaangkop ba ang bagong device sa iyong patakaran sa pagpapatala? Tatlong kundisyon ang nagpapasya, isa lamang ang nagbibigay-katwiran sa muling paggawa.

Ano ang talagang sinisira ng muling paggawa

Ang muling pagsisimula ng PKI ay pinapalitan ang directory ng walang laman na istruktura: bagong CA key at sertipiko, walang laman na database ng pag-isyu at bagong counter ng serye. Hindi kusang sumusunod ang mga kliyente; ang kanilang profile ay nagpi-pin sa lumang CA, kaya bawat device ay dapat magpatala muli, at ang hindi maabot ay mano-mano.

Ang mas tahimik na pagkalugi ay ang pagtutuos. Nakadepende ang pagbawi sa pag-alam kung aling mga serial number ang inisyu mo at kanino. Burahin ang index at makakapirma ka pa rin, ngunit hindi mo na masasabi nang may katiyakan kung alin sa mga naisyung sertipiko ang gusto mong bawiin. Ang CA directory na may mga sertipiko na walang tugmang estado ng issuer ay backup na nagbabalik ng maling kalahati ng sistema.

Ang pagkopya ng pribadong key ng CA sa tabi ng tumatakbong server ay ang isa pang shortcut na dapat tanggihan: ginagawa nitong file pa sa isang host na may hindi mapagkakatiwalaang trapiko ang awtoridad sa pagpirma na dapat nasa labas ng network.

Unang kundisyon: naaabot pa ba ang estado ng issuer

Hanapin muna ang directory na talagang pinagkakatiwalaan ng server bago magpasya. Ihambing ang sertipikong ipinapakita ng server bilang CA sa nasa PKI directory sa pamamagitan ng fingerprint, hindi sa pangalan ng file:

openssl x509 -in ca.crt -noout -fingerprint -sha256
openssl x509 -in /etc/openvpn/ca.crt -noout -fingerprint -sha256

Kung tugma ang fingerprint, ang pagpapatala ay dagdag at wala kang muling gagawin. Kung magkaiba, pumipirma ka gamit ang CA na hindi pinagkakatiwalaan ng server: naipapasok nang malinis ang sertipiko ngunit nabigo sa handshake, at ang error na iyon ay maling nasuri bilang bug ng kliyente nang maraming oras.

Pagkatapos, hanapin ang estado ng pag-isyu: ang index file, ang counter ng serye at ang file ng CRL number. Kung wala ang index ngunit buhay ang key, makakapag-isyu ka, ngunit minamana mo ang problema sa pagtatala ng pagbawi. Itala iyon sa talaan ng pagbabago, dahil ilalantad ito ng susunod na kahilingan sa pagbawi.

Ikalawang kundisyon: sino ang may hawak ng bagong pribadong key

Ito ang desisyong nararamdaman ng mga gumagamit, kaya gawin ito nang tahasan. Ang key na nilikha sa kliyente at ipinadala bilang kahilingan ay nag-iiwan ng pribadong kalahati sa device mula sa unang utos, at hindi ito hinahawakan ng administrador. Ang key na nilikha sa server ay mas madali para sa mga device na walang kasangkapan, ngunit ginagawa nitong tagapag-alaga ng bawat key ang administrador at pinalalaki ang epekto ng kompromiso sa server.

Sa Easy-RSA 3 laban sa umiiral na CA, ang pag-import at pagpirma ng kahilingan ay dalawang utos:

./easyrsa import-req /tmp/alice.req alice
./easyrsa sign-req client alice

Piliin ang uri ng sertipiko nang sadya. Ang kahilingang pinirmahan bilang sertipiko ng server sa halip na kliyente ay gumagawa ng file na mukhang maayos at tinatanggihan ng kapares, at bihirang sabihin ng mensahe ng error kung bakit. Sa openssl ca, ang parehong pagpili ay nasa mga extension na ipinapasa mo, hindi sa default na seksyon.

Ikatlong kundisyon: kailangan ba ng server ng higit sa sertipiko

Para sa karaniwang OpenVPN na may pagpapatotoo sa sertipiko, ang sertipiko mismo ang pagpapatala: nagiging pagkakakilanlan ng kliyente ang common name, at anumang directory, itinulak na ruta o static na address ay nakabatay sa pangalang iyon. Idagdag ang sertipiko at kalimutan ang configuration, kokonekta ang tunnel ngunit hindi lalabas ang mga kailangang ruta.

Binabago ito ng mga platform. Ang OpenVPN Access Server ay may sariling database ng gumagamit, kaya ang pinirmahang sertipiko ay hindi account; dapat umiral ang account at pinahihintulutan. Ang ibang gateway ay nag-uugnay ng string ng pagkakakilanlan sa isang grupo. Ang pagpapatala ng isang device ay karaniwang humahawak ng dalawang sistema, at ang sertipiko ay ang una lamang.

Ang dagdag na pamamaraan at kung kailan tama ang muling paggawa

Ang pagkakasunod-sunod na nagdaragdag ng isang device nang walang pinsala: kumpirmahin ang issuer sa fingerprint, kumuha ng sariwang backup ng PKI directory, i-import at pirmahan ang kahilingan para sa papel ng kliyente, ihatid ang sertipiko kasama ang kadena nito sa aprubadong channel, at i-verify bago kumonekta ang gumagamit:

openssl verify -CAfile ca.crt alice.crt
openssl x509 -in alice.crt -noout -subject -issuer -dates -purpose

Dapat ipakita ng purpose line ang SSL client. Tapusin sa pag-update ng backup ng CA pagkatapos ng pag-isyu, dahil ang backup na kinuha bago maitala ang bagong serial number ay nagbabalik ng estadong walang device na kararagdag mo lang.

Tama ang muling paggawa sa tatlong sitwasyon: nakompromiso ang key ng CA, nawala nang hindi na mababalik ang estado ng pag-isyu, o sadyang binabago mo ang algorithm ng key o patakaran ng sertipiko. Tatlo silang proyekto na nangangailangan ng plano sa muling pagpapatala para sa bawat kliyente, hindi mga hakbang sa isang kahilingan para sa isang device. Kung wala sa mga ito, magpatala nang dagdag at iwanan ang issuer.