Tenu vian VPN-radikan CA eksterrete kaj tamen eldonu atestilojn
Tenu la radikan ŝlosilon for de la reto, subskribu foliajn atestilojn per intera CA, publikigu CRL ĝustatempe kaj testu la ĉenon antaŭ ol la unua kliento konektiĝas.
Via VPN respondas al konektoj je la 3-a horo nokte, dum la maŝino, kiu subskribas ĝiajn atestilojn, restas malŝaltita en tirkao. Kliento, kiu validigas la servilan atestilon, neniam kontaktas vian CA, do la CA ne devas esti atingebla por iu ajn konekto. La parto, kiu postulas planadon, estas la tago, kiam atestilo devas esti eldonita, renovigita aŭ revokita dum la radika ŝlosilo restas ŝlosita.
Kion konekto efektive validigas
Kiam la kliento OpenVPN konektiĝas, ĝi trairas la subskriban ĉenon de la folia atestilo de la servilo supren al CA-atestilo, kiun ĝi jam fidas, kontrolas la validecan fenestron kaj, se la profilo tion diras, konsultas revokan liston. Ĝi neniam serĉas vian radikan CA-n. La servilo faras la spegulan aferon por klientaj atestiloj. Je konekta tempo ĉeestas nur la folia atestilo, la intera atestilo kaj la fida fasko, kiun vi disdonis antaŭe.
Kio efektive malsukcesas estas unu el tri aferoj: la subskriba ŝlosilo ne disponeblas ĉe eldono, revoka listo malnoviĝis, aŭ la fida fasko de la kliento estas pli malnova ol la ĉeno, kiun la servilo prezentas. La unua estas problema pri procezo; la aliaj du estas problemoj pri disdonado. Neniu el ili postulas, ke la radika ŝlosilo estu enrete, kaj administrita VPN-servo, kiu postulas privatan atestilon por tunela aŭtentikigo, nur movas la subskriban aŭtoritaton al la provizanto. Azure punkto-al-ejo funkcias inverse: vi alŝutas radikan atestilon kaj atestiloj subskribitaj sub ĝi estas fidataj, do demandu, kiu subskribas, kiu validigas kaj kiel atestilo estas retirata frue.
Konstruu la radikon sur gastiganto, kiu neniam ricevas adreson
Eksterreta radiko estas uzata malofte: por subskribi la atestilon de la intera CA kaj poste por renovigi aŭ revoki ĝin. Ĉio alia okazas unu nivelon malsupre. Faru la radikan laboron sur maŝino tenata for de la reto, se eble el viva sistemo, kaj registru, kiu estis en la ĉambro. La komandoj supozas OpenSSL 1.1.1 aŭ pli novan, ĉar -addext ne haveblas en pli malnovaj konstruoj.
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"
Kreu la interan atestilon sur la subskriba gastiganto kaj portu nur ĝian peton al la eksterreta maŝino. La radiko subskribas tiun peton kun voja longo nulo, do la intera CA rajtas subskribi finpunktajn atestilojn sed ne rajtas krei alian CA sub si. Tiu unu etendaĵo malhelpas kompromititan subskriban gastiganton produkti aŭtoritaton egalvaloran al la radiko. Uzu ECDSA nur se ĉiu kliento funkciigas OpenVPN 2.4 aŭ pli novan; alie generu RSA-ŝlosilojn kaj konservu la saman fluon.
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 enhavas basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign kaj authorityKeyIdentifier=keyid:always. Redonu la radikan ŝlosilon al ĝia kesto antaŭ ol la subskriba gastiganto reekonektiĝos. Se la radiko devas povi revoki la interan atestilon, subskribu ĝin per openssl ca -config root.cnf -extensions intermediate_ca kontraŭ radiknivela index.txt anstataŭ openssl x509 -req, por ke la seria numero estu registrita; poste sendu la rezultan radikan liston ene de la klienta profilo, kie dosiera crl-verify legas ĝin ĉe lanĉo. Sendu al klientoj faskon kun ambaŭ CA-atestiloj; sola folia atestilo ne validiĝos kontraŭ la radiko.
Eldonu foliajn atestilojn el la intera CA, kun datumbazo
Subskribo per openssl x509 -req funkcias ĝis vi bezonos revokon, ĉar nenio registras la serian numeron. Uzu openssl ca ekde la unua atestilo, por ke seria numero, eksvalidiĝo kaj revoka stato vivu en unu datumbazo. Kreu la datumbazajn dosierojn unufoje, poste direktu la agordon al ili:
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
La linio pri ŝlosila uzo supozas ECDSA-ŝlosilon; aldonu keyEncipherment por RSA. Donu al ĉiu kliento propran komunan nomon, ĉar OpenVPN identigas konekton per tiu kampo, kaj du tekkomputiloj kunhavantaj CN=vpn-client ne estas distingeblaj en protokoloj, en reguloj de client-config-dir aŭ en iu ajn puŝo por uzanto, kaj vi perdas la atribuon, kiu faras revokan decidon defendebla. Eldonu kaj validigu folian atestilon tiel:
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
Tenu la subskriban ŝlosilon malantaŭ politika limo anstataŭ kopii ĝin al la VPN-gastiganto: malgranda servo, kiu aŭtentikigas la peton, kontrolas la komunan nomon kontraŭ permeslisto kaj redonas nur la atestilon. Registru ĉiun serian numeron; la protokolo estas la sola ligo inter atestilo kaj la persono, kiu petis ĝin.
Publikigu revokon sen veki la radikon
Klientajn atestilojn revokas la intera CA, neniam la radiko. La radika listo gravas nur kiam intera CA estas bruligita. Direktu la servilon al la intera listo per crl-verify. Dosiera CRL estas ŝarĝata ĉe serva lanĉo, do reŝargu post ĉiu regenerado; la dosieruja formo legas staton ĉe konekta tempo kaj kostas unu dosieron por seria numero.
Revoku kaj regeneru per du komandoj el la sama datumbazo:
openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem
Poste observu la horloĝon. CRL portas kampon por sekva ĝisdatigo, kaj kiam tiu dato pasis, validiga partnero malakceptas la liston anstataŭ ignori ĝin. Ĉiumonata regenerado per default_crl_days = 30 lasas spacon; ĉiujara ne. Pli mallongaj vivdaŭroj de folioj estas la pli fidinda kontrolo, ĉar revoko validas nur tie, kie la listo estas konsultata.
Testu la ĉenon, poste skribu la ceremonion
Reproduktu kvar malsukcesojn antaŭ ol fidi la dezajnon. Validigu la ĉenon per openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Konektiĝu per eksvalidiĝinta klienta atestilo kaj konfirmu, ke la servilo malakceptas ĝin. Revoku testan klienton, reŝargu kaj konfirmu, ke la listo ekvalidas. Antaŭenigu la horloĝon de gastiganto je unu tago, ĉar malĝusta horloĝo povas eldoni kaj malakcepti atestilojn, kiuj ŝajnas validaj aliloke.
Eksterreta radiko estas kontrolo nur se la paperoj ekzistas: du nomitaj homoj por la ceremonio, registro de ĉiu subskribita seria numero, ĉifrita rezerva kopio tenata aparte de la maŝino kaj restaŭra testado sur izolita gastiganto. Subskribu rezervan interan atestilon dum la sama ceremonio, por ke mortinta subskriba gastiganto ne devigu vin malŝlosi la radikon noktomeze.
Antaŭ ol nomi ĝin finita, konfirmu kvin aferojn: la radika ŝlosilo ne estas sur reta gastiganto, la intera ŝlosilo vivas nur sur la subskriba gastiganto, la klienta fasko portas ambaŭ CA-atestilojn, la CRL havas estontan sekvan ĝisdatigon, kaj iu posedas kalendaran enskribon por ĉiu eksvalidiĝo en la ĉeno. Se unu mankas, la agordo, kiu aspektas eksterreta, estas simple nedokumentita.