Laikykite VPN šakninę CA neprisijungusią ir vis tiek išduokite sertifikatus

Jūsų VPN atsako į prisijungimus 3 valandą nakties, o mašina, kuri pasirašo jo sertifikatus, guli išjungta stalčiuje. Klientas, tikrinantis serverio sertifikatą, niekada nesusisiekia su jūsų CA, todėl CA neturi būti pasiekiama jokiam prisijungimui. Dalis, kuriai reikia planavimo, yra diena, kai sertifikatą reikia išduoti, atnaujinti arba atšaukti kol šakninis raktas lieka užrakintas.

Ką prisijungimas iš tikrųjų tikrina

Kai OpenVPN klientas prisijungia, jis pereina parašų grandinę nuo serverio lapo sertifikato iki CA sertifikato, kuriuo jau pasitiki, patikrina galiojimo langą ir, jei profilis taip nurodo, pasižiūri atšaukimo sąrašą. Jis niekada neieško jūsų šakninės CA. Serveris atlieka veidrodinį veiksmą klientų sertifikatams. Prisijungimo metu yra tik lapas, tarpinis sertifikatas ir anksčiau išplatintas pasitikėjimo paketas.

Iš tikrųjų nepavyksta vienas iš trijų dalykų: pasirašymo raktas nepasiekiamas išdavimo metu, atšaukimo sąrašas pasenęs arba kliento pasitikėjimo paketas senesnis už grandinę, kurią pateikia serveris. Pirmasis yra proceso problema; kiti du yra platinimo problemos. Nė vienas jų nereikalauja, kad šakninis raktas būtų prisijungęs, o valdoma VPN paslauga, kuri tunelio autentifikavimui reikalauja privataus sertifikato, tik perkelia pasirašymo teisę paslaugų teikėjui. Azure taškas į vietą veikia atvirkščiai: įkeliate šakninį sertifikatą ir jo pagrindu pasirašyti sertifikatai laikomi patikimais, todėl klauskite, kas pasirašo, kas tikrina ir kaip sertifikatas atšaukiamas anksčiau.

Sukurkite šaknį pagrindiniame kompiuteryje, kuris niekada negauna adreso

Neprisijungusi šaknis naudojama retai: tarpinės CA sertifikatui pasirašyti, o vėliau jį atnaujinti arba atšaukti. Viskas kita vyksta vienu lygiu žemiau. Šaknies darbus atlikite kompiuteryje, laikomame už tinklo ribų, jei įmanoma iš gyvos sistemos, ir užrašykite, kas buvo kambaryje. Komandos numato OpenSSL 1.1.1 arba naujesnę versiją, nes -addext senesniuose rinkiniuose nėra.

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"

Sukurkite tarpinį sertifikatą pasirašymo pagrindiniame kompiuteryje ir nuneškite tik jo užklausą į neprisijungusį kompiuterį. Šaknis pasirašo tą užklausą nulinio kelio ilgio, todėl tarpinė CA gali pasirašyti galinių taškų sertifikatus, bet negali sukurti kitos CA po savimi. Šis vienas plėtinys neleidžia sukompromituotam pasirašymo kompiuteriui sukurti šakniai lygiavertės institucijos. ECDSA naudokite tik jei kiekvienas klientas naudoja OpenVPN 2.4 arba naujesnę versiją; kitu atveju sugeneruokite RSA raktus ir palikite tą patį srautą.

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 turi basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign ir authorityKeyIdentifier=keyid:always. Grąžinkite šakninį raktą į jo seifą prieš vėl prijungiant pasirašymo kompiuterį. Jei šaknis turi galėti atšaukti tarpinį sertifikatą, pasirašykite jį su openssl ca -config root.cnf -extensions intermediate_ca prieš šaknies lygio index.txt, o ne su openssl x509 -req, kad būtų įrašytas serijos numeris; tada nusiųskite gautą šaknies sąrašą kliento profilyje, kur failinis crl-verify jį nuskaito paleidimo metu. Siųskite klientams paketą su abiem CA sertifikatais; vien lapas nebus patikrintas prieš šaknį.

Išduokite lapus iš tarpinės CA, su duomenų baze

Pasirašymas su openssl x509 -req veikia tol, kol nereikia atšaukti, nes niekas neįrašo serijos numerio. Naudokite openssl ca nuo pirmo sertifikato, kad serijos numeris, galiojimas ir atšaukimo būsena gyventų vienoje duomenų bazėje. Sukurkite duomenų bazės failus vieną kartą, tada nukreipkite konfigūraciją į juos:

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

Rakto naudojimo eilutė numato ECDSA raktą; RSA pridėkite keyEncipherment. Suteikite kiekvienam klientui savo bendrą vardą, nes OpenVPN identifikuoja prisijungimą pagal tą lauką, o du nešiojamieji, bendrinantys CN=vpn-client, negali būti atskirti žurnaluose, client-config-dir taisyklėse ar bet kuriame vartotojo push, ir prarandate priskyrimą, kuris daro atšaukimo sprendimą apginamą. Išduokite ir patikrinkite lapą taip:

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

Laikykite pasirašymo raktą už politikos ribos, o ne kopijuokite jį į VPN pagrindinį kompiuterį: maža paslauga, kuri autentifikuoja užklausą, tikrina bendrą vardą pagal leistinų sąrašą ir grąžina tik sertifikatą. Registruokite kiekvieną serijos numerį; žurnalas yra vienintelė sąsaja tarp sertifikato ir žmogaus, kuris jo paprašė.

Skelbkite atšaukimą nepažadinę šaknies

Klientų sertifikatus atšaukia tarpinė CA, niekada šaknis. Šaknies sąrašas svarbus tik tada, kai tarpinė CA sudeginama. Nukreipkite serverį į tarpinį sąrašą su crl-verify. Failinis CRL įkeliamas paleidžiant paslaugą, todėl įkelkite iš naujo po kiekvieno pergeneravimo; katalogo forma skaito būseną prisijungimo metu ir kainuoja vieną failą kiekvienam serijos numeriui.

Atšaukite ir pergeneruokite dviem komandomis iš tos pačios duomenų bazės:

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

Tada stebėkite laikrodį. CRL turi kito atnaujinimo lauką, o kai ta data praeina, tikrinantis partneris atmeta sąrašą, o ne ignoruoja jį. Mėnesinis pergeneravimas su default_crl_days = 30 palieka atsargą; metinis ne. Trumpesnis lapų galiojimas yra patikimesnė kontrolė, nes atšaukimas galioja tik ten, kur sąrašas tikrinamas.

Išbandykite grandinę, tada užrašykite ceremoniją

Atkurkite keturis gedimus prieš pasitikėdami projektu. Patikrinkite grandinę su openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Prisijunkite su pasibaigusiu kliento sertifikatu ir patvirtinkite, kad serveris jį atmeta. Atšaukite bandomąjį klientą, įkelkite iš naujo ir patvirtinkite, kad sąrašas įsigalioja. Pastumkite pagrindinio kompiuterio laikrodį viena diena į priekį, nes neteisingas laikrodis gali išduoti ir atmesti sertifikatus, kurie kitur atrodo galiojantys.

Neprisijungusi šaknis yra kontrolė tik tada, kai yra dokumentai: du įvardyti žmonės ceremonijai, kiekvieno pasirašyto serijos numerio įrašas, užšifruota atsarginė kopija, laikoma atskirai nuo kompiuterio, ir atkūrimo testas izoliuotame pagrindiniame kompiuteryje. Pasirašykite atsarginę tarpinę CA tos pačios ceremonijos metu, kad miręs pasirašymo kompiuteris nepriverstų jūsų atidaryti šaknies vidurnaktį.

Prieš vadindami tai baigtu, patvirtinkite penkis dalykus: šakninis raktas nėra tinkle esančiame kompiuteryje, tarpinis raktas gyvena tik pasirašymo kompiuteryje, kliento paketas turi abu CA sertifikatus, CRL turi būsimą kitą atnaujinimą, ir kažkas turi kalendoriaus įrašą kiekvienam grandinės galiojimo pabaigos terminui. Jei vieno trūksta, neprisijungusiai atrodanti sąranka tiesiog nedokumentuota.