Dyn VPN beantwurdet ferbiningen om 3 oere nachts, wylst de masine dy't syn sertifikaten ûndertekent útskeakele yn in laad leit. In klant dy't it serversertifikaat falidearret, nimt nea kontakt op mei dyn CA, dus de CA hoecht foar gjin inkelde ferbining berikber te wêzen. It part dat planning nedich hat, is de dei dat in sertifikaat útjûn, fernijd of ynlutsen wurde moat wylst de woartelkaai efter slot bliuwt.

Wat in ferbining eins falidearret

As de OpenVPN-klant ferbynt, rint er de hantekeningkeatling fan it blêdsertifikaat fan de server omheech nei in CA-sertifikaat dat er al fertrout, kontrolearret it jildichheidsfinster en rieplachtet, as it profyl dat seit, in ynlûkingslist. Hy siket nea dyn woartel-CA op. De server docht it spegelbyld foar kliïntsertifikaten. Op it momint fan ferbinen binne allinne it blêd, it tuskenlizzende sertifikaat en it fertrouwensbondel datst earder ferspraat hast, oanwêzich.

Wat eins mislearret, is ien fan trije dingen: de ûndertekeningskaai is net beskikber by útjefte, in ynlûkingslist is ferâldere, of it fertrouwensbondel fan 'e klant is âlder as de keatling dy't de server presintearret. It earste is in prosesprobleem; de oare twa binne distribúsjeproblemen. Gjin fan alle ferget dat de woartelkaai online is, en in beheard VPN-tsjinst dy't in priveesertifikaat foar tunnelautentikaasje easket, ferpleatst allinne de ûndertekeningsautoriteit nei de leveransier. Azure punt-nei-site wurket oarsom: do lêdst in woartelsertifikaat op en sertifikaten dy't dêrûnder ûndertekene binne, wurde fertroud, dus freegje wa't ûndertekenet, wa't falidearret en hoe't in sertifikaat betiid weromlutsen wurdt.

Bou de woartel op in host dy't nea in adres krijt

In offline woartel wurdt selden brûkt: om it tuskenlizzende CA-sertifikaat te ûndertekenjen, en letter om it te fernijen of yn te lûken. Al it oare bart ien nivo leger. Doch it woartelwurk op in masine dy't bûten it netwurk holden wurdt, as it kin fan in libben systeem, en skriuw op wa't yn 'e keamer wie. De opdrachten ferwachtsje OpenSSL 1.1.1 of nijer, om't -addext net yn âldere builds sit.

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"

Meitsje it tuskenlizzende sertifikaat op 'e ûndertekeningshost en bring allinne syn oanfraach nei de offline masine. De woartel ûndertekenet dy oanfraach mei in paadlingte fan nul, sadat it tuskenlizzende CA einpuntsertifikaten ûndertekenje mei, mar gjin oare CA ûnder him meitsje mei. Dy iene útwreiding hâldt in kompromittearre ûndertekeningshost tsjin om in woartel-lykweardige autoriteit te meitsjen. Brûk ECDSA allinne as elke klant OpenVPN 2.4 of nijer draait; oars meitsje RSA-kaaien en hâld de flow itselde.

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 befettet basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign en authorityKeyIdentifier=keyid:always. Bring de woartelkaai werom nei syn safe foar't de ûndertekeningshost wer ferbûn wurdt. As de woartel it tuskenlizzende sertifikaat ynlûke kinne moat, ûndertekenje it dan mei openssl ca -config root.cnf -extensions intermediate_ca tsjin in index.txt op woartelnivo ynstee fan openssl x509 -req, sadat it searjenûmer fêstlein wurdt; stjoer dan de resultearjende woartellist yn it klantprofyl, dêr't in bestânsbasearre crl-verify it by it starten lêst. Stjoer klanten in bondel mei beide CA-sertifikaten; in blêd allinne sil net falidearje tsjin 'e woartel.

Jou blêden út fan it tuskenlizzende, mei in databank

Undertekenje mei openssl x509 -req wurket oantst ynlûke moatst, om't neat it searjenûmer fêstleit. Brûk openssl ca fan it earste sertifikaat ôf, sadat searjenûmer, ferfal en ynlûkingsstatus yn ien databank libje. Meitsje de databankbestannen ien kear, rjochtsje dan de konfiguraasje dêrop:

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

De rigel foar kaaiberik jout in ECDSA-kaai oan; foegje keyEncipherment ta foar RSA. Jou elke klant in eigen mienskiplike namme, om't OpenVPN in ferbining oan dat fjild werkent, en twa laptops dy't CN=vpn-client diele, binne net te ûnderskieden yn logs, yn client-config-dir-regels of yn hokker push dan ek per brûker, en do ferliest de taskriuwing dy't in ynlûkingsbeslút ferdigenber makket. Jou in blêd sa út en falidearje it:

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

Hâld de ûndertekeningskaai efter in beliedsgrins ynstee fan him nei de VPN-host te kopiearjen: in lytse tsjinst dy't de oanfraach autentisearret, de mienskiplike namme tsjin in talittingslist kontrolearret en allinne it sertifikaat weromstjoert. Logje elk searjenûmer; it log is de iennige keppeling tusken in sertifikaat en de persoan dy't derom frege hat.

Publisearje ynlûking sûnder de woartel wekker te meitsjen

Kliïntsertifikaten wurde troch it tuskenlizzende ynlutsen, nea troch de woartel. De woartellist is allinne fan belang as in tuskenlizzende ferbaarnd is. Rjochtsje de server mei crl-verify op 'e tuskenlizzende list. In bestânsbasearre CRL wurdt by tsjinststart laden, dus laad op 'e nij nei elke weromrekken; de mapfoarm lêst steat op it momint fan ferbinen en kostet ien bestân per searjenûmer.

Lûk yn en meitsje op 'e nij mei twa opdrachten út deselde databank:

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

Wachtsje dan op 'e klok. In CRL draacht in fjild foar folgjende bywurking, en as dy datum foarby is, wiist in falidearjende partner de list ôf ynstee fan him te negearjen. Moanliks op 'e nij meitsje mei default_crl_days = 30 lit romte; jierliks net. Koartere libbensdagen fan blêden binne de betrouberder kontrôle, om't ynlûking allinne jildt dêr't de list rieplachte wurdt.

Test de keatling, skriuw dan de seremoanje op

Reprodusearje fjouwer mislearrings foar'tst it ûntwerp fertroust. Falidearje de keatling mei openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Ferbyn mei in ferrûn kliïntsertifikaat en befestigje dat de server it wegert. Lûk in testklant yn, laad op 'e nij en befestigje dat de list yn wurking trett. Set de klok fan in host in dei foarút, om't in ferkearde klok sertifikaten útjaan en ôfwize kin dy't earne oars jildich lykje.

In offline woartel is allinne in kontrôle as it papierwurk bestiet: twa neamde minsken foar de seremoanje, in ferslach fan elk ûndertekene searjenûmer, in fersifere reservekopie dy't apart fan 'e masine bewarre wurdt, en in wersteltoets op in isolearre host. Undertekenje by deselde seremoanje in reserve-tuskenlizzende, sadat in deade ûndertekeningshost dy net twingt de woartel middernacht iepen te meitsjen.

Foar'tst it klear neamst, befestigje fiif dingen: de woartelkaai sit net op in oan it netwurk ferbûne host, de tuskenlizzende kaai libbet allinne op 'e ûndertekeningshost, it klantbondel draacht beide CA-sertifikaten, de CRL hat in takomstige folgjende bywurking, en immen hat in kalenderitem foar elk ferfal yn 'e keatling. As ien mist, is de opset dy't offline liket gewoan ûndokumintearre.

Relatearre artikelen