Halten Sie Ihre VPN-Root-CA offline und stellen Sie trotzdem Zertifikate aus

Ihr VPN beantwortet Verbindungen um 3 Uhr morgens, während die Maschine, die seine Zertifikate signiert, ausgeschaltet in einer Schublade liegt. Ein Client, der das Serverzertifikat prüft, kontaktiert niemals Ihre CA, also muss die CA für keine Verbindung erreichbar sein. Der Teil, der Planung braucht, ist der Tag, an dem ein Zertifikat ausgestellt, erneuert oder widerrufen werden muss während der Root-Schlüssel weggeschlossen bleibt.

Was eine Verbindung tatsächlich prüft

Wenn sich der OpenVPN-Client verbindet, geht er die Signaturkette vom Blattzertifikat des Servers hinauf zu einem CA-Zertifikat, dem er bereits vertraut, prüft das Gültigkeitsfenster und zieht, wenn das Profil es vorsieht, eine Sperrliste zu Rate. Er sucht niemals Ihre Root-CA nach. Der Server macht das Spiegelbild für Client-Zertifikate. Zum Verbindungszeitpunkt sind nur das Blatt, die Zwischen-CA und das Vertrauensbündel vorhanden, das Sie zuvor verteilt haben.

Was tatsächlich scheitert, ist eines von drei Dingen: Der Signaturschlüssel ist bei der Ausstellung nicht verfügbar, eine Sperrliste ist veraltet, oder das Vertrauensbündel des Clients ist älter als die Kette, die der Server vorlegt. Das erste ist ein Prozessproblem; die anderen beiden sind Verteilungsprobleme. Keines von ihnen verlangt, dass der Root-Schlüssel online ist, und ein verwalteter VPN-Dienst, der ein privates Zertifikat für die Tunnelauthentifizierung verlangt, verlagert die Signaturautorität nur zum Anbieter. Azure Point-to-Site funktioniert umgekehrt: Sie laden ein Root-Zertifikat hoch, und darunter signierte Zertifikate gelten als vertrauenswürdig; fragen Sie also, wer signiert, wer prüft und wie ein Zertifikat vorzeitig zurückgezogen wird.

Bauen Sie die Root auf einem Host, der nie eine Adresse bekommt

Eine Offline-Root wird selten genutzt: um das Zwischen-CA-Zertifikat zu signieren und später, um es zu erneuern oder zu widerrufen. Alles andere geschieht eine Ebene tiefer. Erledigen Sie die Root-Arbeit auf einer Maschine, die vom Netz ferngehalten wird, möglichst von einem Live-System aus, und protokollieren Sie, wer im Raum war. Die Befehle setzen OpenSSL 1.1.1 oder neuer voraus, weil -addext in älteren Builds fehlt.

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"

Erzeugen Sie die Zwischen-CA auf dem Signaturhost und tragen Sie nur deren Anfrage zur Offline-Maschine. Die Root signiert diese Anfrage mit einer Pfadlänge von null, sodass die Zwischen-CA Endpunktzertifikate signieren, aber keine weitere CA unter sich erzeugen darf. Diese eine Erweiterung hindert einen kompromittierten Signaturhost daran, eine root-gleichwertige Autorität zu prägen. Verwenden Sie ECDSA nur, wenn jeder Client OpenVPN 2.4 oder neuer ausführt; erzeugen Sie sonst RSA-Schlüssel und halten Sie den Ablauf identisch.

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 enthält basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign und authorityKeyIdentifier=keyid:always. Legen Sie den Root-Schlüssel zurück in seinen Safe, bevor der Signaturhost wieder verbunden wird. Muss die Root die Zwischen-CA widerrufen können, signieren Sie sie mit openssl ca -config root.cnf -extensions intermediate_ca gegen eine index.txt auf Root-Ebene statt mit openssl x509 -req, damit die Seriennummer erfasst wird; liefern Sie dann die resultierende Root-Liste im Clientprofil aus, wo ein dateibasiertes crl-verify sie beim Start liest. Liefern Sie Clients ein Bündel mit beiden CA-Zertifikaten; ein Blatt allein wird nicht gegen die Root validiert.

Stellen Sie Blätter von der Zwischen-CA aus, mit einer Datenbank

Signieren mit openssl x509 -req funktioniert, bis Sie widerrufen müssen, weil nichts die Seriennummer erfasst. Verwenden Sie openssl ca ab dem ersten Zertifikat, damit Seriennummer, Ablauf und Sperrstatus in einer Datenbank leben. Legen Sie die Datenbankdateien einmal an und richten Sie dann die Konfiguration darauf aus:

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

Die Key-Usage-Zeile setzt einen ECDSA-Schlüssel voraus; fügen Sie keyEncipherment für RSA hinzu. Geben Sie jedem Client einen eigenen Common Name, denn OpenVPN identifiziert eine Verbindung über dieses Feld, und zwei Laptops, die CN=vpn-client teilen, lassen sich in Protokollen, in client-config-dir-Regeln oder in irgendeinem Push pro Benutzer nicht unterscheiden, und Sie verlieren die Zuordnung, die eine Widerrufsentscheidung verteidigbar macht. Stellen Sie ein Blatt so aus und prüfen Sie es:

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

Halten Sie den Signaturschlüssel hinter einer Policy-Grenze, statt ihn auf den VPN-Host zu kopieren: ein kleiner Dienst, der die Anfrage authentifiziert, den Common Name gegen eine Allowlist prüft und nur das Zertifikat zurückgibt. Protokollieren Sie jede Seriennummer; das Protokoll ist die einzige Verbindung zwischen einem Zertifikat und der Person, die es angefordert hat.

Veröffentlichen Sie Widerrufe, ohne die Root zu wecken

Client-Zertifikate werden von der Zwischen-CA widerrufen, nie von der Root. Die Root-Liste zählt nur, wenn eine Zwischen-CA verbrannt ist. Richten Sie den Server mit crl-verify auf die Zwischenliste. Eine dateibasierte CRL wird beim Dienststart geladen, also laden Sie nach jeder Neuerzeugung neu; die Verzeichnisform liest den Zustand beim Verbindungsaufbau und kostet eine Datei pro Seriennummer.

Widerrufen und erzeugen Sie neu mit zwei Befehlen aus derselben Datenbank:

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

Beobachten Sie dann die Uhr. Eine CRL trägt ein Feld für die nächste Aktualisierung, und sobald dieses Datum vorbei ist, weist ein prüfender Peer die Liste zurück, statt sie zu ignorieren. Monatliches Neuerzeugen mit default_crl_days = 30 lässt Spielraum; jährliches nicht. Kürzere Blattlebensdauern sind die verlässlichere Kontrolle, denn Widerruf gilt nur dort, wo die Liste herangezogen wird.

Testen Sie die Kette und schreiben Sie dann die Zeremonie auf

Reproduzieren Sie vier Fehler, bevor Sie dem Entwurf trauen. Prüfen Sie die Kette mit openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt. Verbinden Sie sich mit einem abgelaufenen Client-Zertifikat und bestätigen Sie, dass der Server es ablehnt. Widerrufen Sie einen Testclient, laden Sie neu und bestätigen Sie, dass die Liste wirkt. Stellen Sie eine Host-Uhr einen Tag vor, denn eine falsche Uhr kann Zertifikate ausstellen und ablehnen, die anderswo gültig aussehen.

Eine Offline-Root ist nur eine Kontrolle, wenn der Papierkram existiert: zwei benannte Personen für die Zeremonie, eine Aufzeichnung jeder signierten Seriennummer, ein verschlüsseltes Backup, getrennt von der Maschine gelagert, und ein Wiederherstellungstest auf einem isolierten Host. Signieren Sie während derselben Zeremonie eine Ersatz-Zwischen-CA, damit ein toter Signaturhost Sie nicht um Mitternacht die Root aufschließen lässt.

Bevor Sie das für fertig erklären, bestätigen Sie fünf Dinge: Der Root-Schlüssel liegt nicht auf einem vernetzten Host, der Zwischenschlüssel lebt nur auf dem Signaturhost, das Client-Bündel trägt beide CA-Zertifikate, die CRL hat eine künftige nächste Aktualisierung, und jemand besitzt einen Kalendereintrag für jeden Ablauf in der Kette. Fehlt eines, ist das Setup, das offline aussieht, nur undokumentiert.