Panatilihin ang OpenVPN CA Signing Key sa Labas ng /etc/openvpn

Dalawang direktoryo na magkamukha sa isang tutorial ay gumagawa ng lubos na magkaibang trabaho. Ang isa ay naglalaman ng certificate authority: ang pribadong key nito, ang counter ng serial number at ang talaan ng lahat ng pinirmahan nito. Ang isa ay naglalaman ng kailangan ng daemon upang magsimula at maglingkod sa mga kliyente. Ang ilagay ang dalawa sa parehong host sa ilalim ng parehong account ay maginhawa para sa isang hapon at magastos para sa natitirang buhay ng deployment, dahil ang daemon ay tumatakbo noon sa tabi ng nag-iisang key na makakagawa ng anumang pagkakakilanlan na gusto nito.

Ano ang nilalaman ng workspace ng CA

Ang direktoryo ng PKI ay estado ng issuer, hindi configuration. Naglalaman ito ng pribadong key at certificate ng CA, isang serial number file, isang index ng mga inisyu na certificate at ang materyal bawat pagkakakilanlan na ginawa mula sa mga ito.

Ang pagpirma ng isang kahilingan ay nagbabago ng estadong iyon, kaya ang workspace ay pag-aari ng account na kontrolado ng administrator sa isang host kung saan hindi tumatakbo ang serbisyo ng VPN. Sinumang makabasa ng pribadong key ng CA ay makakapag-isyu ng certificate na pagtitiwalaan ng server, kaya ang proteksyon ng key ay ang buong modelo ng pagtitiwala sa isang file. Ang pagkopya nito sa pangalawang lokasyon upang makatipid ng isang hakbang ay lumilikha ng pangalawang bagay na poprotektahan at pangalawang bagay na kalilimutan. Ang bawat pirma ay nagdaragdag din ng serial number at nagdadagdag ng entry sa index, kaya ang workspace ay isang kopya ng estado at hindi isang folder ng mga file.

Ang pampublikong certificate ng CA ay iba. Ito ay inilaan upang ipamahagi, at ito ang ginagamit ng mga kliyente at server upang i-verify ang isa’t isa.

Ano ang binabasa ng daemon kapag nagsisimula

Ang tumatakbong server ay gumagamit ng maliit na set: ang sariling certificate, ang sariling pribadong key, ang certificate ng CA para sa pag-verify ng mga peer at anumang keying material na kailangan ng napiling mode. Binabasa nito ang mga landas na iyon sa startup at muli sa reload.

Ang pagmamay-ari ay dapat suriin laban sa unit na aktwal na naglulunsad, hindi laban sa isang interactive na root shell. Ang idineklarang sandboxing ay maaaring gawing read-only o di-nakikita ang bahagi ng filesystem kahit na nagtagumpay ang manu-manong pagsubok bilang root.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

Ang ikatlong linya ang nilalaktawan ng mga tao. Tinatanong nito ang sariling account ng daemon kung mababasa nito ang key, at iyon ang tanging bersyon ng tanong na mahalaga kapag naibagsak na ang mga pribilehiyo. Ang zero exit bilang root ay walang sinasabi tungkol sa nangyayari pagkatapos ng pagbagsak.

Sulit na paghiwalayin ang dalawang landas ng pagkabigo bago mo baguhin ang anumang pahintulot. Ang pagkabigo sa pagpirma ay tumutukoy sa direktoryo ng PKI, sa pahintulot sa paghahanap sa mga parent directory nito at sa account na nagpapatakbo ng issuer. Ang pagkabigo sa startup ay tumutukoy sa unit, sa working directory nito at sa mga landas na pinangalanan sa configuration ng server. Ang gawing nababasa ng lahat ang buong tree ay hindi nag-aayos ng alinman sa dalawa, at inaalis nito ang hangganan na pinagbabasehan ng dalawa.

Bakit nabibigo sa kalaunan ang pagkopya ng CA key sa server

Karaniwang nagsisimula ang kopya bilang debugging move: may gustong mag-renew ng kliyente sa host ng VPN, kaya napupunta ang CA key sa /etc/openvpn at gumagana ang renewal. Nagtagumpay ang agarang gawain, at wala na ang hangganan.

Pagkatapos ay naka-backup ang server, at sumasama ang signing authority sa mga backup. Ang snapshot, support bundle o kopya ng configuration directory ay nagdadala na ngayon ng kakayahang mag-isyu ng pinagkakatiwalaang pagkakakilanlan hangga’t valid ang CA. Sinumang may hawak ng kopyang iyon ay makakagawa ng certificate para sa anumang pangalan na tinatanggap ng server, kabilang ang mga pangalang hindi kailanman inisyu. Ang tanging talaan ng pag-isyu na iyon ay ang pinipili nilang itago.

Ang pagbangon mula sa estadong iyon ay hindi usapin ng pagtanggal ng file. Kailangan mong magpasya kung na-expose ang key, i-rotate ang CA kung oo, at ipamahagi muli ang pagtitiwala sa bawat peer. Iniiwasan ng hiwalay na workspace ang buong usapan.

Mga account, direktoryo, backup

Bigyan ang issuer ng sariling account at home directory, na inilayo sa host ng VPN kung praktikal. Bigyan ang daemon ng ibang account, na may read access sa naka-deploy na materyal at write access sa wala na nag-isyu ng certificate. I-deploy sa pamamagitan ng pagkopya ng mga pampublikong certificate palabas at hindi kailanman sa paghila ng pribadong estado ng issuer papasok. I-backup ang dalawang papel nang hiwalay, dahil magkaiba ang kanilang sensitivity at ang kanilang mga kuwento ng restore.

Pagkatapos ng revocation, i-update ang CRL file na pinangalanan ng configuration ng server, pagkatapos ay i-reload ang serbisyo upang mabasa ito ng mga bagong koneksyon. Ang dokumentasyon ng Easy-RSA ay sumasaklaw sa layout ng workspace at sa daloy ng pagpirma; ang mga tuntunin ng pagmamay-ari sa paligid nito ay nananatiling desisyon tungkol sa iyong host. Kumpirmahin kung ano ang na-load ng serbisyo gamit ang openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate sa halip na ipagpalagay na nakuha ito ng reload.

Isang pagsubok na nagpapatunay ng paghihiwalay

Suriin ang negatibong kaso, hindi lamang ang gumagana. Pirmahan ang isang certificate mula sa account ng issuer ayon sa disenyo, pagkatapos ay kumpirmahin na hindi kayang simulan ng parehong account ang serbisyo o basahin ang pribadong key ng server. Pagkatapos ay kumpirmahin na hindi kayang basahin ng account ng daemon ang pribadong key ng CA.

Ang tatlong pagsusuring iyon ay tumatagal ng ilang minuto at nakakaligtas sa mga pagbabago ng staff, dahil mga pahayag ang mga ito tungkol sa mga pahintulot at hindi sa ugali. Isulat ang resulta kasama ang mga landas at account na sakop nito, at ang petsa kung kailan mo ito pinatakbo. Ang susunod na taong magmamana ng deployment na ito ay kung hindi ay muling kukuha ng hangganan mula sa isang tutorial na kailanman ay walang ganoon. Ang petsadong talaan din ang dahilan kung bakit ang susunod na pagsusuri ay tumatagal ng ilang minuto sa halip na isang hapon.