Certificate Revocation List überwachen

Letzte Aktualisierung am 01.01.2023, 13:01:49 Uhr

Die Public Key Infrastruktur (PKI) wird heutzutage immer wichtiger und ist nicht mehr wegzudenken. Den meisten dürfte diese im Zusammenhang mit Webseiten und E-Mail-Server bekannt sein. Es werden natürlich auch Zertifikate für die Authentifizierung gegenüber eines WLANs oder VPN-Verbindung eingesetzt.

Gerade in der eigenen Umgebung ist man nicht nur für die Ausstellung, Export und Import von Zertifikaten verantwortlich, sondern muss sich auch regelmäßig mit dem Zurückrufen (Revocation) von bereits ausgestellten Zertifikaten beschäftigen. Bestes Beispiel hierfür ist ein verlorenes/gestohlenes Gerät, dass keinen Zugang mehr zum Netzwerk erhalten soll. Damit verbunden gibt es in jeder PKI für jede Zertifizierungsstelle (Certificate Authority, CA) auch eine oder mehrere Certificate Revocation List/s (CRL/s). Diese Listen müssen je nach Verwendungszweck sowohl im lokalen Netzwerk (LAN) als auch im Internet erreichbar sein.

Die meisten Dienste und Anwendungen (z.B. Browser) führen bei der Nutzung eines SSL-Zertifikats verschiedene Prüfungen (Gültigkeit, Laufzeit, etc.) durch. Des Weiteren wird auch geprüft, ob das SSL-Zertifikat auf der CRL zu finden. Somit muss auch sichergestellt werden, dass die CRL jederzeit gültig ist. Hintergrund ist nämlich, dass diese je nach Konfiguration ein Ablaufdatum hat.

Die Sperrlisten werden grundsätzlich durch die jeweilige CA automatisch aktualisiert, erneuert und gespeichert. Meistens werden die Datei(en) aus Sicherheitsgründen und der notwendigen Verfügbarkeit nicht direkt auf der CA für den Abruf bereitgestellt, sondern auf einem weiteren Server (z.B. in der DMZ) kopiert. Dafür wird von den Verantwortlichen ein (Quick & Dirty) Skript geschrieben.

Die Infrastruktur entwickelt sich über die Tage, Wochen, Monate und Jahre weiter. So dass evtl. das Generieren der CRL und Kopieren der Dateien evtl. eines Tages nicht mehr funktioniert. Umso wichtiger ist es für einen störungsfreien Betrieb nicht nur die CA zu überwachen, sondern auch die CRL(s). Daher habe ich ein PowerShell Skript geschrieben, welches die CRL abruft, ausliest und die Daten aufbereitet. Das Ganze ist für das Produkt PRTG von Paesseler entwickelt worden. Die aktuelle Version steht auf meinem Git Repository zum Download bereit.

Das PowerShell Skript mit demselben oder neuen Dateinamen im Programmverzeichnis „.\Custom Sensors \EXEXML“ der PRTG Probe ablegen. In meiner Testumgebung ist es der Standardpfad (C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML). Falls mehrere PRTG Probes zum Einsatz kommen, natürlich auf dem Server ab speichern der später den Sensor auch ausführen wird.

Anschließend die Weboberfläche von PRTG in einem Browser (Tab) anrufen und anmelden. Zuerst auf der Probe bzw. in der entsprechenden Hierarchie ein neues Gerät anlegen. Selbstverständlich kann der Sensor auch einem bestehenden Gerät hinzugefügt werden.

Mit einem Klick auf „Speichern“ werden die Zugangsdaten geschrieben. Danach einen neuen Sensor dem Gerät hinzufügen. Im Assistenten den Sensortyp „Programm/Skript (Erweitert)“ auswählen.

Nun erscheint der Dialog für die Allgemeinen- und Sensoreinstellungen für den neuen Sensor.

Erklärung der notwendigen Variablen im Feld Parameter.

Parameter Beschreibung
%host Als erster Parameter muss „%host“ eingegeben werden. Grund dafür ist, dass ich den Computernamen im PowerShell Skript in eine Variable gepackt habe. Somit ist dieses flexibel einsetzbar. Unabhängig von der Probe und Gerätenamen. PRTG speichert den Computernamen des übergeordneten Geräts in der Variablen %host. Das ist auch in der Dokumentation von PRTG nachzulesen.
URL der CRL Als zweiter Parameter muss die vollständige Adresse (Full Qualified Domain Name, FQDN) der zu überwachenden Sperrliste (Certification Reocation List, CRL) angegeben werden. Diese findet man in den Eigenschaften des SSL-Zertifikats. In diesem Fall handelt es sich um die CRL der CA von Let’s Encrypt.

Sind alle Einstellungen und ein schöner Name für den Sensor vergeben, kann der Sensor erstellt werden. So sieht das Ergebnis des Sensors aus.

Der Code bzw. Sensor ist sozusagen noch BETA. Ich habe diesen in zwei Umgebungen bereits im Einsatz. Somit würde ich mich natürlich freuen, wenn sich weitere Tester finden lassen.

Viel Spaß beim Ausprobieren. 🙂

Abonnieren
Benachrichtige mich bei
6 Comments
neueste
älteste
Inline Feedbacks
View all comments
Danny
05.01.2024 08:05

Ich habe letztes Jahr eine neue PKI bei uns im Unternehmen aufgebaut und bin durch Zufall hier auf den Artikel gestoßen.
Die Einrichtung war ganz easy, aber ich bekomme folgende Fehlermeldung vom Sensor zurück. „Unable to connect to the remote server“
Ich habe den Sensor laut Anleitung eingerichtet und folgendes in die Parameter eingetragen „%host „http://CRLURL/CertEnroll/meinecrl.crl“

Mike
07.10.2022 09:14

Perfekt,
vielen Dank dafür. Gestern hatte ich gerade das Problem das die Liste nicht aktualisiert wurde.
Nun sollte das für die Zukunft kein Problem mehr sein.
Btw. ich musste auch den vollständigen Pfad URL+CRL als Parameter angeben

Bene
14.07.2022 12:03

Vielen Dank – genau das, was ich gesucht habe.
Wir monitoren die CRL einer internen PKI – entgegen der Beschreibung musste ich die komplette URL+CRL angegeben, damit der Sensor funktioniert.

%host "http://webserver.domain.de/dateiname.crl"
Ben
29.06.2022 11:05

1000 Dank.
Gerade installiert. Werde beobachten und gegebenenfalls Berichten.