Panatilihing offline ang root CA ng iyong VPN at maglabas pa rin ng mga sertipiko

Sinasagot ng iyong VPN ang mga koneksyon nang alas-3 ng madaling araw habang ang makinang pumipirma sa mga sertipiko nito ay nakapatay sa isang drawer. Ang kliyenteng nagbe-validate ng sertipiko ng server ay hindi kailanman kumokontak sa iyong CA, kaya hindi kailangang maabot ang CA para sa anumang koneksyon. Ang bahaging nangangailangan ng pagpaplano ay ang araw na kailangang ilabas, i-renew o bawiin ang isang sertipiko habang nakakandado ang root key.

Ano ang aktwal na vine-validate ng isang koneksyon

Kapag kumonekta ang OpenVPN client, dinadaanan nito ang chain ng lagda mula sa leaf certificate ng server pataas hanggang sa CA certificate na pinagkakatiwalaan na nito, tinitingnan ang validity window at, kung sinasabi ng profile, tumitingin sa revocation list. Hindi nito hinahanap kailanman ang iyong root CA. Ginagawa ng server ang salamin nito para sa mga certificate ng kliyente. Sa sandali ng koneksyon, ang leaf, ang intermediate at ang trust bundle na ipinamahagi mo kanina lang ang naroroon.

Ang talagang nabibigo ay isa sa tatlong bagay: hindi available ang signing key sa paglabas, luma na ang revocation list, o mas matanda ang trust bundle ng kliyente kaysa sa chain na inihaharap ng server. Ang una ay problema sa proseso; ang dalawa ay problema sa distribusyon. Wala sa mga ito ang nangangailangan na ang root key ay online, at ang managed VPN service na humihingi ng pribadong sertipiko para sa tunnel authentication ay inililipat lang ang signing authority sa provider. Ang Azure point-to-site ay kabaligtaran: nag-a-upload ka ng root certificate at ang mga sertipikong pinirmahan sa ilalim nito ay pinagkakatiwalaan, kaya itanong kung sino ang pumipirma, sino ang nagbe-validate at paano binabawi nang maaga ang isang sertipiko.

Itayo ang root sa isang host na hindi kailanman nakakakuha ng address

Bihirang gamitin ang offline root: para pirmahan ang certificate ng intermediate CA at mamaya para i-renew o bawiin ito. Nangyayari ang lahat ng iba pang isang antas pababa. Gawin ang trabaho sa root sa makinang itinatabi sa labas ng network, kung posible mula sa live system, at itala kung sino ang nasa silid. Ipinapalagay ng mga command ang OpenSSL 1.1.1 o mas bago, dahil wala ang -addext sa lumang build.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

Gumawa ng intermediate sa signing host at dalhin lamang ang request nito sa offline machine. Pinipirmahan ng root ang request na iyon na may zero path length, kaya maaaring pumirma ang intermediate CA sa mga endpoint certificate ngunit hindi ito makakagawa ng ibang CA sa ilalim nito. Ang nag-iisang extension na iyon ay pumipigil sa kompromisong signing host na gumawa ng awtoridad na katumbas ng root. Gumamit ng ECDSA lamang kung tumatakbo ang bawat kliyente sa OpenVPN 2.4 o mas bago; kung hindi, gumawa ng RSA key at panatilihing pareho ang daloy.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext ay naglalaman ng basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign at authorityKeyIdentifier=keyid:always. Ibalik ang root key sa vault bago muling konektahin ang signing host. Kung dapat mabawi ng root ang intermediate, pirmahan ito gamit ang openssl ca -config root.cnf -extensions intermediate_ca laban sa index.txt sa antas ng root sa halip na openssl x509 -req, upang maitala ang serial number; pagkatapos ay ipadala ang resultang root list sa profile ng kliyente, kung saan binabasa ito ng file-based na crl-verify sa pagsisimula. Magpadala sa mga kliyente ng bundle na may dalawang CA certificate; ang leaf lamang ay hindi mabe-validate laban sa root.

Maglabas ng mga leaf mula sa intermediate, may database

Gumagana ang pagpirma gamit ang openssl x509 -req hanggang kailanganin mong bawiin, dahil walang nagtatala ng serial number. Gamitin ang openssl ca mula sa unang sertipiko upang ang serial number, expiry at revocation state ay manirahan sa isang database. Gumawa ng database files isang beses, pagkatapos ay ituro ang configuration sa mga ito:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

Ipinapalagay ng key usage line ang ECDSA key; magdagdag ng keyEncipherment para sa RSA. Bigyan ang bawat kliyente ng sarili nitong common name, dahil OpenVPN kinikilala ang koneksyon sa field na iyon, at ang dalawang laptop na nagbabahagi ng CN=vpn-client ay hindi matutukoy sa mga log, sa mga tuntunin ng client-config-dir o sa anumang push kada user, at nawawala mo ang attribution na nagpapaging depensable sa desisyon sa pagbawi. Ilabas at i-validate ang leaf nang ganito:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

Panatilihin ang signing key sa likod ng policy boundary sa halip na kopyahin ito sa VPN host: isang maliit na serbisyo na nagpapatunay ng request, sumusuri ng common name laban sa allowlist at nagbabalik lamang ng sertipiko. Itala ang bawat serial number; ang log ang tanging link sa pagitan ng isang sertipiko at ng taong humingi nito.

Ilathala ang pagbawi nang hindi ginigising ang root

Ang mga certificate ng kliyente ay binabawi ng intermediate, hindi kailanman ng root. Ang root list ay mahalaga lamang kapag ang isang intermediate ay nasunog. Ituro ang server sa intermediate list gamit ang crl-verify. Ang file-based na CRL ay nilo-load sa pagsisimula ng serbisyo, kaya i-reload ito pagkatapos ng bawat regenerasyon; ang directory form ay nagbabasa ng estado sa sandali ng koneksyon at gumagasta ng isang file kada serial number.

Bawiin at i-regenerate gamit ang dalawang command mula sa parehong database:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

Pagkatapos ay bantayan ang orasan. Ang CRL ay may field para sa susunod na update, at kapag lumipas ang petsang iyon, tinatanggihan ng nagbe-validate na peer ang listahan sa halip na balewalain ito. Ang buwanang regenerasyon gamit ang default_crl_days = 30 ay nag-iiwan ng espasyo; ang taunan ay hindi. Ang mas maiikling leaf lifetime ang mas maaasahang kontrol, dahil ang pagbawi ay nalalapat lamang kung saan tinitingnan ang listahan.

Subukan ang chain, pagkatapos ay isulat ang seremonya

Kopyahin ang apat na pagkabigo bago magtiwala sa disenyo. I-validate ang chain gamit ang openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Kumonekta gamit ang isang nag-expire na certificate ng kliyente at tiyaking tinatanggihan ito ng server. Bawiin ang isang test client, i-reload at tiyaking nagkakabisa ang listahan. Isulong ang orasan ng isang host nang isang araw, dahil ang maling orasan ay makakapaglabas at makakatanggi ng mga sertipikong mukhang valid sa ibang lugar.

Ang offline root ay kontrol lamang kung may mga papeles: dalawang taong pinangalanan para sa seremonya, talaan ng bawat pinirmahang serial number, naka-encrypt na backup na itinatabi hiwalay sa makina, at pagsubok sa pag-restore sa isang isolated host. Pirmahan ang isang ekstrang intermediate sa parehong seremonya upang ang patay na signing host ay hindi ka pilitin buksan ang root sa hatinggabi.

Bago mo itong tawaging tapos, tiyakin ang limang bagay: wala ang root key sa isang naka-network na host, nabubuhay lamang ang intermediate key sa signing host, dinadala ng client bundle ang dalawang CA certificate, may susunod na update sa hinaharap ang CRL, at may kalendaryong entry ang isang tao para sa bawat expiry sa chain. Kung may kulang, ang setup na mukhang offline ay hindi lamang dokumentado.