Nutzen Sie Ihre bestehende Unternehmens-CA für OpenVPN-Peers

Nichts an OpenVPN erfordert, dass das Zertifikat von Easy-RSA stammt, und eine Flotte, die bereits eine organisatorische PKI besitzt, sollte normalerweise keine zweite aufbauen. Die eigentliche Arbeit besteht nicht darin, ein Werkzeug zu wählen, sondern zu entscheiden, was die ausgegebenen Identitäten bedeuten, welche Peers der Tunnel akzeptiert und wie Erneuerung und Sperrung beim Prüfer ankommen. Arbeiten Sie die fünf Schritte unten der Reihe nach durch, denn ein späterer Schritt kann eine im ersten getroffene Rollenentscheidung nicht reparieren.

Vergeben Sie zwei Rollen statt einer gemeinsamen Identität

Jeder Peer braucht ein eigenes Zertifikat und einen passenden privaten Schlüssel. Bitten Sie das PKI-Team um eine Serveridentität mit Serververwendung und um getrennte Clientidentitäten mit Clientverwendung, damit der Tunnel beide beim Handshake unterscheiden kann.

Widerstehen Sie den Abkürzungen, die unter Termindruck auftauchen. Ein auf Laptops kopierter Schlüssel eines Webservers löscht die Unterscheidung, auf der die Rollenprüfung beruht, und ein auf einem VPN-Endpunkt installierter CA-Signaturschlüssel macht aus einem kompromittierten Host eine kompromittierte Hierarchie. Ein PKCS12-Bündel kann einen Endpunktschlüssel und seine Kette tragen, aber es gewährt niemals die Erlaubnis, diese Identität in einer anderen Rolle wiederzuverwenden.

Verdrahten Sie die Vertrauenseingaben auf jeder Seite

Client und Server brauchen jeweils einen Vertrauensanker, ihre eigene Identität und eine ausdrückliche Rollenerwartung. Ein Client-Fragment, das alle drei angibt, sieht so aus.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Die Serverseite spiegelt das mit remote-cert-tls client und ihrem eigenen Zertifikat, und genau das verhindert, dass ein Clientzertifikat als Server akzeptiert wird. Die Namensprüfung ist eine von der Rollenprüfung getrennte Entscheidung. Lesen Sie die ausgerollte Konfiguration, um zu sehen, welches Feld verglichen wird, statt eine Hostnamen-Übereinstimmung nach Browserart anzunehmen. Beide Seiten sollten außerdem ausdrücklich sagen, welchem Aussteller sie vertrauen, denn ein gemeinsam genutzter Dateipfad in der Flotte ist nicht dasselbe wie eine gemeinsame Richtlinie.

Liefern Sie Zwischenzertifikate aus, ohne das Vertrauen zu erweitern

Die beiden Seiten müssen nicht eine Ausstellungskette teilen. Wenn ein Peer ein von einer Zwischenstelle signiertes Zertifikat vorlegt, braucht die prüfende Seite diese Zwischenstelle verfügbar, und OpenVPN unterscheidet die Vertrauensanker-Eingabe von den zusätzlichen Zertifikaten, die zum Vervollständigen einer lokal vorgelegten Kette dienen. Die TLS-Optionsreferenz von OpenVPN 2.6 dokumentiert beides.

Eine Zwischen-CA ist nicht an sich ein Problem, eine breite Unternehmenswurzel im Vertrauensbündel schon. Je breiter der Anker, desto mehr Zertifikate bestehen die Kettenprüfung, und eine Rollenprüfung macht daraus keine Liste autorisierter Mitarbeiter. Verengen Sie den Anker auf den Aussteller, der VPN-Identitäten tatsächlich signiert, wo die Hierarchie es zulässt. Wenn nicht, dokumentieren Sie den breiteren Anker als bewusst akzeptiertes Risiko, statt ihn implizit zu lassen.

Vereinbaren Sie mit dem PKI-Team, wie Erneuerung und Sperrung die VPN-Prüfer erreichen, einschließlich der Frage, welche Aussteller zählen und wer die Liste veröffentlicht. Ein in ein Zertifikat eingebetteter CRL-Verteilungspunkt ist eine Anweisung, kein Beweis dafür, dass ihn jemand abgerufen hat.

Entscheiden Sie, wie die Sperrung tatsächlich ankommt

crl-verify veranlasst den Prüfer, eine Datei oder einen Endpunkt zu konsultieren, und diese Regelung braucht einen Verantwortlichen und einen Aktualisierungspfad. Eine Liste, die beim Rollout einmal kopiert wird, hört stillschweigend auf, Sie zu schützen, sobald ein Zertifikat gesperrt wird.

Notieren Sie die erwartete Verbreitungszeit und testen Sie sie mit einem Zertifikat, das Sie zu sperren bereit sind. Lässt sich die Liste auf dem VPN-Host nicht aktualisieren, ist die Alternative eine kürzere Gültigkeitsdauer plus ein Erneuerungsprozess, der tatsächlich läuft, nicht die Annahme, die Sperrung funktioniere, weil eine URL existiert.

Belegen Sie die Akzeptanz mit einem echten Client

Verbinden Sie einen Client, der zugelassen werden soll, und bestätigen Sie die ausgehandelten Zertifikatsdetails im Protokoll. Probieren Sie dann die Fälle, die scheitern müssen: ein als Server vorgelegtes Clientzertifikat, ein Zertifikat eines Ausstellers außerhalb des Vertrauensankers und ein gesperrtes Zertifikat, falls Sie eines übrig haben.

Halten Sie den akzeptierten Aussteller, die Rollenprüfung und die Sperrquelle neben dem Profil fest. Dieser Eintrag ist es, den der nächste Ingenieur braucht, wenn ein Gerät, das letzten Monat funktionierte, die Verbindung nicht mehr herstellt, und er ist auch der Beleg dafür, dass die Unternehmens-CA innerhalb einer dokumentierten Akzeptanzgrenze genutzt wird und nicht als allgemeine Vertrauensablage.