Hold VPN-rot-CA-en offline og utsted likevel sertifikater

VPN-et ditt svarer på tilkoblinger klokken 3 om natten mens maskinen som signerer sertifikatene står avslått i en skuff. En klient som validerer serversertifikatet kontakter aldri CA-en din, så CA-en trenger ikke være tilgjengelig for noen tilkobling. Delen som krever planlegging, er dagen da et sertifikat må utstedes, fornyes eller tilbakekalles mens rotnøkkelen forblir innelåst.

Hva en tilkobling faktisk validerer

Når OpenVPN-klienten kobler til, går den gjennom signaturkjeden fra serverens løvsertifikat opp til et CA-sertifikat den allerede stoler på, sjekker gyldighetsvinduet og, hvis profilen sier det, slår opp en tilbakekallingsliste. Den slår aldri opp rot-CA-en din. Serveren gjør speilbildet for klientsertifikater. På tilkoblingstidspunktet er bare løvet, mellomleddet og tillitspakken du distribuerte tidligere, til stede.

Det som faktisk feiler, er én av tre ting: signeringsnøkkelen er utilgjengelig ved utstedelse, en tilbakekallingsliste er blitt utdatert, eller klientens tillitspakke er eldre enn kjeden serveren presenterer. Det første er et prosessproblem; de to andre er distribusjonsproblemer. Ingen av dem krever at rotnøkkelen er på nett, og en administrert VPN-tjeneste som krever et privat sertifikat for tunnelautentisering, flytter bare signeringsmyndigheten til leverandøren. Azure punkt-til-område virker motsatt: du laster opp et rotsertifikat, og sertifikater signert under det regnes som klarerte, så spør hvem som signerer, hvem som validerer, og hvordan et sertifikat trekkes tilbake tidlig.

Bygg roten på en vert som aldri får en adresse

En offline rot brukes sjelden: til å signere sertifikatet til den mellomliggende CA-en og senere fornye eller tilbakekalle det. Alt annet skjer ett nivå lenger ned. Gjør rotarbeidet på en maskin som holdes utenfor nettverket, om mulig fra et live-system, og noter hvem som var i rommet. Kommandoene forutsetter OpenSSL 1.1.1 eller nyere, fordi -addext ikke finnes 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 bare forespørselen til den offline maskinen. Roten signerer forespørselen med null sti-lengde, så den mellomliggende CA-en kan signere endepunktsertifikater, men kan ikke opprette en ny CA under seg. Den ene utvidelsen hindrer en kompromittert signeringsvert i å lage en rotlikeverdig myndighet. Bruk ECDSA bare hvis hver klient kjører OpenVPN 2.4 eller nyere; ellers generer RSA-nøkler og hold 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 inneholder basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign og authorityKeyIdentifier=keyid:always. Legg rotnøkkelen tilbake i hvelvet før signeringsverten kobles til igjen. Hvis roten må kunne tilbakekalle mellomleddet, signer det med openssl ca -config root.cnf -extensions intermediate_ca mot en index.txt på rotnivå i stedet for openssl x509 -req, slik at serienummeret registreres; send deretter den resulterende rotlisten i klientprofilen, der en filbasert crl-verify leser den ved oppstart. Send klientene en pakke med begge CA-sertifikatene; et løv alene valideres ikke mot roten.

Utsted løv fra mellomleddet, med en database

Signering med openssl x509 -req fungerer til du trenger å tilbakekalle, fordi ingenting registrerer serienummeret. Bruk openssl ca fra det første sertifikatet, slik at serienummer, utløp og tilbakekallingsstatus lever i én database. Opprett databasefilene én gang, og pek deretter konfigurasjonen mot dem:

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

Linjen for nøkkelbruk forutsetter en ECDSA-nøkkel; legg til keyEncipherment for RSA. Gi hver klient sitt eget vanlige navn, fordi OpenVPN identifiserer en tilkobling etter det feltet, og to bærbare maskiner som deler CN=vpn-client kan ikke skilles i logger, i client-config-dir-regler eller i noen push per bruker, og du mister tilskrivningen som gjør en tilbakekallingsbeslutning forsvarlig. Utsted og valider et løv 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

Hold signeringsnøkkelen bak en policygrense i stedet for å kopiere den til VPN-verten: en liten tjeneste som autentiserer forespørselen, sjekker det vanlige navnet mot en tillatt-liste og bare returnerer sertifikatet. Logg hvert serienummer; loggen er den eneste koblingen mellom et sertifikat og personen som ba om det.

Publiser tilbakekalling uten å vekke roten

Klientsertifikater tilbakekalles av mellomleddet, aldri av roten. Rotlisten betyr noe bare når et mellomledd er brent. Pek serveren mot mellomlisten med crl-verify. En filbasert CRL lastes ved tjenestestart, så last den på nytt etter hver regenerering; katalogformen leser tilstand ved tilkobling og koster én fil per serienummer.

Tilbakekall og regenerer med to kommandoer fra samme 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å klokken. En CRL bærer et felt for neste oppdatering, og når den datoen er passert, avviser en validerende part listen i stedet for å ignorere den. Månedlig regenerering med default_crl_days = 30 gir slakk; årlig gjør det ikke. Kortere løvlevetider er den mer pålitelige kontrollen, fordi tilbakekalling bare gjelder der listen konsulteres.

Test kjeden, og skriv deretter ned seremonien

Reproduser fire feil før du stoler på designet. Valider kjeden med openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Koble til med et utløpt klientsertifikat og bekreft at serveren avviser det. Tilbakekall en testklient, last på nytt og bekreft at listen trer i kraft. Flytt klokken på en vert en dag frem, fordi en feil klokke kan utstede og avvise sertifikater som ser gyldige ut andre steder.

En offline rot er bare en kontroll hvis papirene finnes: to navngitte personer for seremonien, en oversikt over hvert signert serienummer, en kryptert sikkerhetskopi lagret adskilt fra maskinen, og en gjenopprettingstest på en isolert vert. Signer et reserve-mellomledd under samme seremoni, slik at en død signeringsvert ikke tvinger deg til å låse opp roten ved midnatt.

Før du kaller det ferdig, bekreft fem ting: rotnøkkelen er ikke på en nettverkskoblet vert, mellomleddnøkkelen lever bare på signeringsverten, klientpakken bærer begge CA-sertifikatene, CRL-en har en fremtidig neste oppdatering, og noen eier en kalenderoppføring for hvert utløp i kjeden. Hvis én mangler, er oppsettet som ser offline ut, bare udokumentert.