Ich betreibe einen OpenVPN-Server für einige IoT-Geräte und bei vielen dieser Geräte müssen die Zertifikate ersetzt werden, da die alten abgelaufen sind. Das Aktualisieren dieser Zertifikate ist ein instabiler, manueller Prozess, der langsame mobile Verbindungen verwendet, und außerdem kann auf diese Geräte nur über OVPN zugegriffen werden. Aus diesem Grund möchte ich besonders sicherstellen, dass die Zertifikate erfolgreich ersetzt wurden und neue Verbindungen mithilfe dieser Zertifikate hergestellt werden. Das Problem ist, dass ich keinen einigermaßen einfachen Weg finde, um genügend Details von OVPN zu erhalten, um beispielsweise die Seriennummern oder die Ausgabezeit der ersetzten Zertifikate anzuzeigen.
Wie protokolliert man also Zertifikatsdetails für jede Verbindung in OpenVPN?
Am besten wäre eine zusätzliche Spalte im Statusprotokoll, aber selbst--status-version 2scheint keine zusätzlichen Details aus den Zertifikaten bereitzustellen. Dinge wie der allgemeine Name der Zertifikate sind bei alten und neuen Zertifikaten gleich. Gibt es Unterstützung für zusätzliche benutzerdefinierte Spalten basierend auf intern verfügbaren Daten?
Ich habe zusätzlich die Protokollebene auf 9 erhöht, aber neben der Protokollierung vieler paketbezogener Dinge auf niedriger Ebene habe ich auch keine zusätzlichen Zertifikatsdetails von Clients gesehen. Je nach Protokollebene könnten jedoch leicht Dinge übersehen werden, sodass etwas, das nur diese Zertifikatsdetails selbst protokolliert, ohnehin vorzuziehen wäre.
Konzepte wie --client-connectund --learn-addressscheinen ebenfalls nur allgemeine Namen bereitzustellen. Da die Dinge außerdem nur von vorübergehendem Interesse sind, möchte ich die Implementierung einer zu kundenspezifischen Software für diesen Fall vermeiden.
Danke!
Antwort1
Meine Frage besteht eigentlich aus zwei Teilen: Wie protokolliere ich etwas Interessantes und wie erreiche ich mein Ziel, sicherzustellen, dass kein altes Zertifikat mehr verwendet wird. Die Antwort ist also ebenfalls unterschiedlich.
Protokollierung
Ich habe zwar keine einfache Konfiguration gefunden, um zusätzliche Details wie Zertifikatsserien zu protokollieren, aber das kann mit Hilfe von--tls-verify. Dies erfordert ein Skript und für dieses Skript setzt OVPN mehrere Umgebungsvariablen, die beispielsweise die Seriennummer eines Zertifikats enthalten.
–tls-verify-BefehlFühren Sie den Befehl cmd aus, um den X509-Namen einer ausstehenden TLS-Verbindung zu überprüfen, die ansonsten alle anderen Zertifizierungstests bestanden hat (mit Ausnahme des Widerrufs über die Direktive „–crl-verify“; der Widerrufstest erfolgt nach „–tls-verifytest“).
Die unterstützten Umgebungsvariablen:
tls_id_{n}
tls_serial_{n}
tls_serial_hex_{n}
Obwohl es sich nicht um eine Protokollierung im eigentlichen Sinn handelt, --tls-export-certkönnte es ebenfalls interessant sein, da es theoretisch das gesamte Zertifikat eines Clients auf dem Server für eine detaillierte Analyse verfügbar macht.
–tls-export-cert-VerzeichnisSpeichern Sie die Zertifikate, die die Clients bei der Verbindung mit diesem Verzeichnis verwenden. Dies geschieht, bevor –tls-verify aufgerufen wird. Die Zertifikate verwenden einen temporären Namen und werden gelöscht, wenn das Skript tls-verify zurückkehrt. Der für das Zertifikat verwendete Dateiname ist über die Umgebungsvariable peer_cert verfügbar.
Ungültige Zertifikate ablehnen
Mein oberstes Ziel ist es, sicherzustellen, dass ein ersetztes Zertifikat wie erwartet verwendet wird. Ein Ansatz hierfür ist die Verwendung einer Zertifikatsperrliste, und OVPN unterstützt eine sehr einfache Möglichkeit, dies zu tun: Man benötigt kein konkretes Dateiformat oder ähnliches mit den Zertifikaten, sondern kann einfach einige Dateinamen zu einem konfigurierten Verzeichnis hinzufügen, und alle Zertifikate, die die Seriennummer enthalten, die einem bestimmten Dateinamen entspricht, werden blockiert. Das Wichtigste, was Sie beachten müssen, ist, dass die Dateinamen Zertifikatsseriennummern in Dezimalschreibweise sein müssen, alles andere ist ziemlich einfach.
–crl-verify crl ['dir']Überprüfen Sie das Peer-Zertifikat anhand der Datei crl im PEM-Format.[...]Wenn das optionale Dir-Flag angegeben ist, aktivieren Sie einen anderen Modus, in dem crl ein Verzeichnis ist, das Dateien enthält, die als widerrufene Seriennummern benannt sind (die Dateien können leer sein, der Inhalt wird nie gelesen). Wenn ein Client eine Verbindung anfordert, bei der die Seriennummer des Client-Zertifikats (Dezimalzeichenfolge) der Name einer im Verzeichnis vorhandenen Datei ist, wird diese abgelehnt.
server.confenthält einfach die folgende zusätzliche Konfiguration:
crl-verify 'crl' 'dir'
Es wird dem folgenden Verzeichnis zugeordnet:
crl
7
8
9
crl_staging
12
13
14
openvpn-status.log
server.conf
Die Dateien in crlund crl_stagingsind einfach die dezimalen Zertifikatserien und können bei Bedarf zwischen den Verzeichnissen verschoben werden. Wenn eine Serie in verfügbar ist crl, wird die Verbindung blockiert, andernfalls ist sie erfolgreich. Eine Beispielfehlermeldung in den Protokollen sieht wie folgt aus:
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 TLS: new session incoming connection from [AF_INET]34.252.35.124:35231 (via [AF_INET][...]%eth1)
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 VERIFY OK: depth=1, C=DE, ST=[...], O=[...], OU=[...], CN=[...], emailAddress=[...]
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 VERIFY CRL: certificate serial number 10 is revoked
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 TLS_ERROR: BIO read tls_read_plaintext error
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 TLS Error: TLS object -> incoming plaintext read error
ovpn-server[15859]: 00-0a-14-81-d9-e1/34.252.35.124:35231 TLS Error: TLS handshake failed