Gamitin ang iyong umiiral na enterprise CA para sa mga peer ng OpenVPN

Wala sa OpenVPN ang nangangailangan na ang sertipiko ay mula sa Easy-RSA, at ang isang fleet na mayroon nang organizational PKI ay karaniwang hindi dapat magtayo ng pangalawa. Ang tunay na gawain ay hindi ang pagpili ng tool kundi ang pagpapasya kung ano ang ibig sabihin ng mga inilabas na pagkakakilanlan, aling mga peer ang tinatanggap ng tunnel, at kung paano dumarating ang renewal at revocation sa verifier. Dumaan sa limang hakbang sa ibaba nang sunod-sunod, dahil ang huling hakbang ay hindi maaaring ayusin ang desisyon sa papel na ginawa sa una.

Maglabas ng dalawang papel sa halip na isang pinagsasaluhang pagkakakilanlan

Bawat peer ay nangangailangan ng sarili nitong sertipiko at tugmang pribadong susi. Hilingin sa pangkat ng PKI ang isang pagkakakilanlan ng server na may paggamit ng server at hiwalay na mga pagkakakilanlan ng kliyente na may paggamit ng kliyente, upang makilala ng tunnel ang dalawa sa oras ng handshake.

Labanan ang mga shortcut na lumilitaw sa ilalim ng panggigipit ng deadline. Ang isang susi ng web server na kinopya sa mga laptop ay nagbubura ng pagkakaibang nakasalalay sa pagsusuri ng papel, at ang isang susi ng paglagda ng CA na naka-install sa endpoint ng VPN ay nagiging sanhi ng isang kompromitadong host na maging kompromitadong hierarchy. Ang isang pakete ng PKCS12 ay maaaring magdala ng susi ng endpoint at ang kadena nito, ngunit hindi kailanman nagbibigay ng pahintulot na gamitin muli ang pagkakakilanlang iyon sa ibang papel.

Ikonekta ang mga input ng tiwala sa bawat panig

Ang kliyente at ang server ay nangangailangan ng tig-iisang anchor ng tiwala, sariling pagkakakilanlan at malinaw na inaasahan sa papel. Ang isang bahagi ng kliyente na nagsasaad ng tatlo ay ganito ang hitsura.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Ang panig ng server ay sumasalamin dito gamit ang remote-cert-tls client at ang sarili nitong sertipiko, at ito ang pumipigil sa isang sertipiko ng kliyente na tanggapin bilang server. Ang pagsusuri ng pangalan ay isang desisyong hiwalay sa pagsusuri ng papel. Basahin ang naka-deploy na configuration upang makita kung aling field ang inihahambing sa halip na ipagpalagay ang pagtutugma ng hostname na parang browser. Dapat ding maging malinaw ang dalawang panig kung aling issuer ang pinagkakatiwalaan nila, dahil ang pinagsasaluhang landas ng file sa buong fleet ay hindi katulad ng pinagsasaluhang patakaran.

Ihatid ang mga intermediate nang hindi pinalalawak ang tiwala

Ang dalawang panig ay hindi kailangang magsalu-salo ng isang kadena ng paglabas. Kapag ang isang peer ay nagpakita ng sertipikong nilagdaan ng isang intermediate, kailangan ng panig na nagbe-verify ang intermediate na iyon na magagamit, at hinihiwalay ng OpenVPN ang input ng anchor ng tiwala mula sa mga karagdagang sertipiko na ginagamit upang kumpletuhin ang isang kadenang iniharap nang lokal. Ang sanggunian ng mga opsyon sa TLS ng OpenVPN 2.6 ay nagdodokumento ng pareho.

Ang isang intermediate CA ay hindi likas na problema, ngunit ang isang malawak na ugat ng enterprise na itinapon sa bundle ng tiwala ay problema. Habang lumalawak ang anchor, mas maraming sertipiko ang pumasa sa pagsubok ng kadena, at ang pagsusuri ng papel ay hindi ginagawa iyon na listahan ng awtorisadong kawani. Paliitin ang anchor sa issuer na talagang lumalagda ng mga pagkakakilanlan ng VPN kung saan pinapayagan ng hierarchy. Kung hindi, idokumento ang mas malawak na anchor bilang sadyang tinatanggap na panganib sa halip na iwanan itong implicit.

Sumang-ayon sa pangkat ng PKI kung paano dumarating ang renewal at revocation sa mga verifier ng VPN, kabilang kung aling mga issuer ang mahalaga at sino ang naglalathala ng listahan. Ang isang distribution point ng CRL na naka-embed sa isang sertipiko ay isang tagubilin, hindi patunay na may kumuha nito.

Magpasya kung paano talaga dumarating ang revocation

crl-verify ay nagiging dahilan upang kumonsulta ang verifier sa isang file o endpoint, at ang kaayusang iyon ay nangangailangan ng may-ari at landas ng pag-refresh. Ang isang listahang kinopya nang isang beses sa panahon ng deployment ay tahimik na humihinto sa pagprotekta sa iyo sa unang pagkakataon na ma-revoke ang isang sertipiko.

Isulat ang inaasahang oras ng pagpapalaganap at subukan ito gamit ang isang sertipikong handa kang i-revoke. Kung hindi ma-refresh ang listahan sa host ng VPN, ang alternatibo ay isang mas maikling panahon ng bisa kasama ang isang proseso ng renewal na talagang tumatakbo, hindi ang pagpapalagay na gumagana ang revocation dahil may URL.

Patunayan ang pagtanggap gamit ang isang tunay na kliyente

Ikonekta ang isang kliyenteng dapat payagan at kumpirmahin ang napagkasunduang detalye ng sertipiko sa log. Pagkatapos ay subukan ang mga kaso na dapat mabigo: isang sertipiko ng kliyente na iniharap bilang server, isang sertipiko mula sa isang issuer sa labas ng anchor ng tiwala, at isang na-revoke na sertipiko kung mayroon kang isang sobra.

Itala ang tinanggap na issuer, ang pagsusuri ng papel at ang pinagmulan ng revocation sa tabi ng profile. Ang talaang iyon ang kailangan ng susunod na inhinyero kapag ang isang device na gumana noong nakaraang buwan ay huminto sa pagkonekta, at ito rin ang patunay na ang enterprise CA ay ginagamit sa loob ng dokumentadong hangganan ng pagtanggap sa halip na bilang isang tambakan ng tiwala para sa pangkalahatang layunin.