Hald VPN-rot-CA-en offline og utsted likevel sertifikat

VPN-et ditt svarar på tilkoplingar klokka 3 om natta medan maskina som signerer sertifikata står avslått i ein skuff. Ein klient som validerer serversertifikatet kontaktar aldri CA-en din, så CA-en treng ikkje vere tilgjengeleg for noka tilkopling. Delen som krev planlegging, er dagen då eit sertifikat må utstedast, fornyast eller tilbakekallast medan rotnøkkelen blir verande innelåst.

Kva ei tilkopling faktisk validerer

Når OpenVPN-klienten koplar til, går han gjennom signaturkjeda frå lauvsertifikatet til serveren opp til eit CA-sertifikat han allereie stolar på, sjekkar gyldigheitsvindauget og, om profilen seier det, slår opp i ei tilbakekallingsliste. Han slår aldri opp rot-CA-en din. Serveren gjer spegelbiletet for klientsertifikat. På tilkoplingstidspunktet er berre lauvet, mellomleddet og tillitspakka du distribuerte tidlegare, til stades.

Det som faktisk feilar, er éin av tre ting: signeringsnøkkelen er utilgjengeleg ved utsteding, ei tilbakekallingsliste er blitt utdatert, eller tillitspakka til klienten er eldre enn kjeda serveren presenterer. Det første er eit prosessproblem; dei to andre er distribusjonsproblem. Ingen av dei krev at rotnøkkelen er på nett, og ein administrert VPN-teneste som krev eit privat sertifikat for tunnelautentisering, flyttar berre signeringsmyndet til leverandøren. Azure punkt-til-område verkar motsett: du lastar opp eit rotsertifikat, og sertifikat signerte under det blir rekna som klarerte, så spør kven som signerer, kven som validerer og korleis eit sertifikat blir trekt tilbake tidleg.

Bygg rota på ein vert som aldri får ei adresse

Ei offline rot blir sjeldan brukt: til å signere sertifikatet til den mellomliggande CA-en og seinare til å fornye eller tilbakekalle det. Alt anna skjer eitt nivå lenger nede. Gjer rotarbeidet på ei maskin som blir halden utanfor nettverket, om mogleg frå eit live-system, og noter kven som var i rommet. Kommandoane føreset OpenSSL 1.1.1 eller nyare, fordi -addext ikkje finst i eldre bygg.

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"

Opprett mellomleddet på signeringsverten og bring berre førespurnaden til den offline maskina. Rota signerer førespurnaden med null sti-lengd, så den mellomliggande CA-en kan signere endepunktsertifikat, men kan ikkje opprette ein ny CA under seg. Den eine utvidinga hindrar ein kompromittert signeringsvert i å lage eit rotlikeverdig myndet. Bruk ECDSA berre om kvar klient køyrer OpenVPN 2.4 eller nyare; elles generer RSA-nøklar og hald flyten identisk.

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 inneheld basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign og authorityKeyIdentifier=keyid:always. Legg rotnøkkelen tilbake i kvelvet før signeringsverten blir kopla til igjen. Om rota må kunne tilbakekalle mellomleddet, signer det med openssl ca -config root.cnf -extensions intermediate_ca mot ein index.txt på rotnivå i staden for openssl x509 -req, slik at serienummeret blir registrert; send deretter den resulterande rotlista i klientprofilen, der ein filbasert crl-verify les ho ved oppstart. Send klientane ei pakke med båe CA-sertifikata; eit lauv åleine validerer ikkje mot rota.

Utsted lauv frå mellomleddet, med ein database

Signering med openssl x509 -req fungerer til du treng å tilbakekalle, fordi ingenting registrerer serienummeret. Bruk openssl ca frå det første sertifikatet, slik at serienummer, utløp og tilbakekallingsstatus lever i éin database. Opprett databasefilene éin gong, og peik deretter konfigurasjonen mot dei:

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

Linja for nøkkelbruk føreset ein ECDSA-nøkkel; legg til keyEncipherment for RSA. Gi kvar klient sitt eige vanlege namn, fordi OpenVPN identifiserer ei tilkopling etter det feltet, og to berebare maskiner som deler CN=vpn-client kan ikkje skiljast i loggar, i client-config-dir-reglar eller i nokon push per brukar, og du mistar tilskrivinga som gjer ei tilbakekallingsavgjerd forsvarleg. Utsted og valider eit lauv slik:

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

Hald signeringsnøkkelen bak ein policygrense i staden for å kopiere han til VPN-verten: ei lita teneste som autentiserer førespurnaden, sjekkar det vanlege namnet mot ei tillaten-liste og berre returnerer sertifikatet. Logg kvart serienummer; loggen er den einaste koplinga mellom eit sertifikat og personen som bad om det.

Publiser tilbakekalling utan å vekkje rota

Klientsertifikat blir tilbakekalla av mellomleddet, aldri av rota. Rotlista har berre noko å seie når eit mellomledd er brend. Peik serveren mot mellomlista med crl-verify. Ein filbasert CRL blir lasta ved tenestestart, så last han på nytt etter kvar regenerering; katalogforma les tilstand ved tilkopling og kostar éi fil per serienummer.

Tilbakekall og regenerer med to kommandoar frå same 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

Følg deretter med på klokka. Ein CRL ber eit felt for neste oppdatering, og når den datoen er passert, avviser ein validerande part lista i staden for å ignorere ho. Månadleg regenerering med default_crl_days = 30 gir slakk; årleg gjer det ikkje. Kortare lauvlevetider er den meir pålitelege kontrollen, fordi tilbakekalling berre gjeld der lista blir konsultert.

Test kjeda, og skriv deretter ned seremonien

Reproduser fire feil før du stolar på designet. Valider kjeda med openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Kople til med eit utløpt klientsertifikat og stadfest at serveren avviser det. Tilbakekall ein testklient, last på nytt og stadfest at lista trer i kraft. Flytt klokka på ein vert ein dag fram, fordi ei feil klokke kan utstede og avvise sertifikat som ser gyldige ut andre stader.

Ei offline rot er berre ein kontroll om papira finst: to namngjevne personar for seremonien, ei oversikt over kvart signert serienummer, ein kryptert tryggingskopi lagra åtskilt frå maskina, og ein gjenopprettingstest på ein isolert vert. Signer eit reserve-mellomledd under same seremonien, slik at ein daud signeringsvert ikkje tvingar deg til å låse opp rota ved midnatt.

Før du kallar det ferdig, stadfest fem ting: rotnøkkelen er ikkje på ein nettverkskopla vert, mellomleddnøkkelen lever berre på signeringsverten, klientpakka ber båe CA-sertifikata, CRL-en har ein framtidig neste oppdatering, og nokon eig ein kalenderoppføring for kvart utløp i kjeda. Om éin manglar, er oppsettet som ser offline ut, berre udokumentert.