Houd uw VPN-root-CA offline en geef toch certificaten uit

Uw VPN beantwoordt verbindingen om 3 uur 's nachts terwijl de machine die de certificaten ondertekent uitgeschakeld in een la ligt. Een client die het servercertificaat valideert, neemt nooit contact op met uw CA, dus de CA hoeft voor geen enkele verbinding bereikbaar te zijn. Het deel dat planning vereist, is de dag waarop een certificaat moet worden uitgegeven, vernieuwd of ingetrokken terwijl de rootsleutel opgesloten blijft.

Wat een verbinding werkelijk valideert

Wanneer de OpenVPN-client verbinding maakt, loopt hij de ondertekeningsketen af van het bladcertificaat van de server omhoog naar een CA-certificaat dat hij al vertrouwt, controleert het geldigheidsvenster en raadpleegt, als het profiel dat zegt, een intrekkingslijst. Hij zoekt nooit uw root-CA op. De server doet het spiegelbeeld voor clientcertificaten. Op het moment van verbinden zijn alleen het blad, de tussenliggende CA en de vertrouwensbundel die u eerder hebt verspreid aanwezig.

Wat werkelijk mislukt, is een van drie dingen: de ondertekeningssleutel is bij uitgifte niet beschikbaar, een intrekkingslijst is verouderd, of de vertrouwensbundel van de client is ouder dan de keten die de server presenteert. Het eerste is een procesprobleem; de andere twee zijn distributieproblemen. Geen ervan vereist dat de rootsleutel online is, en een beheerde VPN-dienst die een persoonlijk certificaat voor tunnelauthenticatie eist, verplaatst alleen de ondertekeningsautoriteit naar de provider. Azure punt-naar-site werkt omgekeerd: u uploadt een rootcertificaat en certificaten die daaronder zijn ondertekend, worden vertrouwd, dus vraag wie ondertekent, wie valideert en hoe een certificaat vroegtijdig wordt ingetrokken.

Bouw de root op een host die nooit een adres krijgt

Een offline root wordt zelden gebruikt: om het certificaat van de tussenliggende CA te ondertekenen en later om het te vernieuwen of in te trekken. Al het andere gebeurt een niveau lager. Doe het rootwerk op een machine die buiten het netwerk wordt gehouden, indien mogelijk vanaf een live systeem, en noteer wie in de kamer was. De opdrachten gaan uit van OpenSSL 1.1.1 of nieuwer, omdat -addext niet in oudere builds zit.

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"

Maak de tussenliggende CA aan op de ondertekeningshost en breng alleen de aanvraag naar de offline machine. De root ondertekent die aanvraag met een padlengte van nul, zodat de tussenliggende CA eindpuntcertificaten mag ondertekenen maar geen andere CA onder zich mag maken. Die ene extensie voorkomt dat een gecompromitteerde ondertekeningshost een root-gelijkwaardige autoriteit maakt. Gebruik ECDSA alleen als elke client OpenVPN 2.4 of nieuwer draait; genereer anders RSA-sleutels en houd de stroom identiek.

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 bevat basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign en authorityKeyIdentifier=keyid:always. Zet de rootsleutel terug in zijn kluis voordat de ondertekeningshost opnieuw wordt verbonden. Als de root de tussenliggende CA moet kunnen intrekken, onderteken die dan met openssl ca -config root.cnf -extensions intermediate_ca tegen een index.txt op rootniveau in plaats van openssl x509 -req, zodat het serienummer wordt vastgelegd; stuur vervolgens de resulterende rootlijst mee in het clientprofiel, waar een op bestanden gebaseerde crl-verify die bij het opstarten leest. Stuur clients een bundel met beide CA-certificaten; een blad alleen valideert niet tegen de root.

Geef bladeren uit vanuit de tussenliggende CA, met een database

Ondertekenen met openssl x509 -req werkt tot u moet intrekken, omdat niets het serienummer vastlegt. Gebruik openssl ca vanaf het eerste certificaat, zodat serienummer, vervaldatum en intrekkingsstatus in één database leven. Maak de databasebestanden één keer aan en wijs de configuratie er vervolgens naar:

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 regel voor sleutelgebruik gaat uit van een ECDSA-sleutel; voeg keyEncipherment toe voor RSA. Geef elke client een eigen algemene naam, omdat OpenVPN een verbinding aan dat veld herkent, en twee laptops die CN=vpn-client delen, zijn niet te onderscheiden in logs, in client-config-dir-regels of in welke push per gebruiker dan ook, en u verliest de toerekening die een intrekkingsbeslissing verdedigbaar maakt. Geef en valideer een blad als volgt:

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

Houd de ondertekeningssleutel achter een beleidsgrens in plaats van hem naar de VPN-host te kopiëren: een kleine dienst die de aanvraag authenticeert, de algemene naam tegen een toegestane lijst controleert en alleen het certificaat teruggeeft. Log elk serienummer; het log is de enige schakel tussen een certificaat en de persoon die erom vroeg.

Publiceer intrekking zonder de root te wekken

Clientcertificaten worden ingetrokken door de tussenliggende CA, nooit door de root. De rootlijst is alleen belangrijk wanneer een tussenliggende CA is verbrand. Wijs de server met crl-verify naar de tussenliggende lijst. Een op bestanden gebaseerde CRL wordt bij de start van de dienst geladen, dus herlaad na elke regeneratie; de mapvorm leest de status op het moment van verbinden en kost één bestand per serienummer.

Trek in en regenereer met twee opdrachten uit dezelfde 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

Let dan op de klok. Een CRL draagt een veld voor de volgende update, en wanneer die datum is verstreken, weigert een validerende partij de lijst in plaats van hem te negeren. Maandelijks regenereren met default_crl_days = 30 laat marge; jaarlijks niet. Kortere bladlevensduren zijn de betrouwbaardere controle, omdat intrekking alleen geldt waar de lijst wordt geraadpleegd.

Test de keten en schrijf daarna de ceremonie op

Reproduceer vier storingen voordat u het ontwerp vertrouwt. Valideer de keten met openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Maak verbinding met een verlopen clientcertificaat en bevestig dat de server het weigert. Trek een testclient in, herlaad en bevestig dat de lijst ingaat. Zet de klok van een host een dag vooruit, omdat een verkeerde klok certificaten kan uitgeven en weigeren die elders geldig lijken.

Een offline root is alleen een beheersmaatregel als het papierwerk bestaat: twee genoemde personen voor de ceremonie, een registratie van elk ondertekend serienummer, een versleutelde back-up die apart van de machine wordt bewaard, en een hersteltest op een geïsoleerde host. Onderteken tijdens dezelfde ceremonie een reserve-tussenliggende CA, zodat een dode ondertekeningshost u niet middernacht de root laat ontgrendelen.

Voordat u het af noemt, bevestigt u vijf dingen: de rootsleutel staat niet op een genetwerkte host, de tussenliggende sleutel leeft alleen op de ondertekeningshost, de clientbundel draagt beide CA-certificaten, de CRL heeft een toekomstige volgende update, en iemand bezit een agenda-item voor elke vervaldatum in de keten. Ontbreekt er één, dan is de opstelling die offline lijkt alleen ongedocumenteerd.