IP-Insider-Workshop: Monitoring mit Checkmk – Teil 12 Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Von Mirco Lang 6 min Lesedauer

Anbieter zum Thema

Ein neues Tool am Monitoring-Himmel: Mit check_cert lassen sich Zertifikate präzise überwachen – als Checkmk-Plugin, Standalone-Tool oder Er­wei­te­rung für andere Systeme. Wie das genau funktioniert, zeigen wir in dieser Folge „Monitoring mit Checkmk“ von unserem Schwesterportal IP-Insider.

Mit check_cert lassen sich SSL/TLS-Zertifikate bis ins Detail prüfen – von Laufzeiten über Signaturverfahren bis hin zu Aussteller-Details.(Bild:  Lang | Checkmk)
Mit check_cert lassen sich SSL/TLS-Zertifikate bis ins Detail prüfen – von Laufzeiten über Signaturverfahren bis hin zu Aussteller-Details.
(Bild: Lang | Checkmk)

Checks auf Zertifikate waren lange Zeit Teil der Website-Checks – zumindest in Checkmk, Nagios und kompatiblen Systemen. Verantwortlich dafür: Das Nagios-Plugin check_http, das seit Ende der 90er seinen Dienst verrichtet. Den Nachfolger check_httpv2 haben die Kollegen von IP-Insider in der letzten Folge der Checkmk-Serie vorgestellt.

Leider beschränkt sich check_http auf die Prüfung der zeitlichen Gültigkeit des Zertifikats – zu wenig für den heutigen Alltag. Auch check_httpv2 leistet diesbezüglich kaum mehr, Checkmk hat lieber ein eigenständiges Tool dafür entwickelt: check_certdas ebenfalls als Standalone-Tool zur Verfügung steht!

Und das ist gut so, denn es gibt viele kleine Bausteine, die für die Sicherheit einer Webseite verantwortlich sind. Dass ein Zertifikat noch nicht abgelaufen ist – gut und schön. Aber was ist, wenn zum Beispiel eine bestimmte TLS-Version für die Transportsicherung vorgesehen ist? Vielleicht sogar bestimmte Signaturverfahren? In besonders sicheren Umgebungen oder beispielsweise bei Diensten, die die Bundesverwaltung nutzt, sind hier ganz konkrete Algorithmen und Kombinationen aus diesen vorgegeben – und müssen entsprechend gemonitort werden.

Oder noch allgemeiner: Soweit es sich um Ihre eigenen Server handelt, sollten Sie sicherstellen, dass auch wirklich Ihre eigenen Zertifikate aktiv sind, nicht bloß solche mit augenscheinlich korrekten Werten.

Mit check_cert ist dies ziemlich problemlos möglich. Sei es als One-Liner im Terminal, als Teil eigener Skripte oder Nagios-kompatibler Monitoring-Systeme wie Checkmk selbst.

Einfacher Check in Checkmk

In Checkmk finden Sie den Zertifikatscheck unter „Setup/Services/HTTP, TCP, email, .../Check certificates“. Natürlich handelt es sich hier um einen aktiven Check, sprich er wird direkt vom Server aus ausgeführt.

Die Konfiguration ist im einfachsten Fall extrem simpel: Sie müssen lediglich einen Namen für den Check vergeben, beispielsweise „IP-Insider“, und die Adresse des Hosts.

Wenn Sie keinerlei weitere Angaben machen, werden folgende, durchaus sinnvolle Vorgaben als Schwellwerte für Statuswechsel auf WARN/CRIT genutzt:

  • Restlaufzeit des Zertifikats: 40/20 Tage
  • Maximale Laufzeit: 90
  • Antwortzeit: 100/200 ms
  • Selbst-signierte Zertifikate erlauben: Nein

Abbildung 1: Überwachte Webseiten können einem bestimmten Host zugeordnet werden.(Bild:  Lang | Checkmk)
Abbildung 1: Überwachte Webseiten können einem bestimmten Host zugeordnet werden.
(Bild: Lang | Checkmk)

Eine Angabe sollten Sie selbst in diesem einfachsten denkbaren Fall setzen: Unter „Conditions“ fehlt noch ein Host, dem dieser Check zugeordnet wird. Wenn es sich um einen überwachten Host handelt, sollte der Check natürlich dort landen. Falls nicht, könnten Sie den Check zum Beispiel einem extra für HTTP- und Zertifikatschecks angelegten Host oder behelfsweise dem Localhost zuordnen, um die Regel zu vervollständigen (siehe Abbildung 1).

Abbildung 2: Das Resultat eines absichtlich auf Warnungen hin konfigurierten Zertifikatscheck.(Bild:  Lang | Checkmk)
Abbildung 2: Das Resultat eines absichtlich auf Warnungen hin konfigurierten Zertifikatscheck.
(Bild: Lang | Checkmk)

Im Monitoring bekommen Sie dann eine simple Auswertung, die neben dem Status und den oben erwähnten Metriken auch einige Zertifikatsdetails liefert, etwa „Issuer CN: R10“, ein Common Name, der sich wiederum Let's Encrypt zuordnen lässt (siehe Abbildung 2).

Präzise Checks

Zertifikate lassen sich allerdings auch deutlich präziser monitoren, nämlich über die Optionen unterhalb von „Check for specific values“. Hier lassen sich für die eigene Infrastruktur alle Datenfelder konkret festlegen, also beispielsweise „Common Name“ von Issuer und Organisation, das Land des Ausstellers. Im Grunde alles, was auch ein Browser ausgibt (siehe Abbildung 3).

Abbildung 3: Wer auf Nummer Sicher gehen will, bildet den Status quo möglichst exakt ab.(Bild:  Lang | Checkmk)
Abbildung 3: Wer auf Nummer Sicher gehen will, bildet den Status quo möglichst exakt ab.
(Bild: Lang | Checkmk)

Besonders interessant erscheinen aber „Serial number“ sowie die Angaben zu verwendeten Algorithmen, sprich „Certificate signature algorithm“ und „Public key algorithm/size“ (siehe Abbildung 4).

Über die Seriennummer können Sie völlig zweifelsfrei verifizieren, dass auf einer Seite exakt das gewünschte Zertifikat läuft. Und über die Angaben zu Schlüsseln und Verschlüsselung können beispielsweise Vorgaben geprüft werden, wie sie etwa vom Bundesamt für Sicherheit in der Informationstechnik für die Nutzung seitens der Bundesverwaltung festgelegt werden.

Abbildung 4: Mit den Crypto-Optionen lassen sich sicherheitstechnische Vorgaben evaluieren.(Bild:  Lang | Checkmk)
Abbildung 4: Mit den Crypto-Optionen lassen sich sicherheitstechnische Vorgaben evaluieren.
(Bild: Lang | Checkmk)

Clevere Host-Zuordnung

Im Artikel zu check_httpv2 haben wir es bereits kurz angerissen: Die Zuordnung zu Hosts lässt sich cleverer bewerkstelligen. Angenommen, Sie möchten sehr viele Zertifikate monitoren und immer wieder neue Endpunkte hinzufügen.

Wenn Sie für alle Endpunkte individuelle Werte vorgeben müssen, bleibt nur die Arbeit mit mehreren Regeln und/oder mehreren Endpunkten in diesen Regeln. In der Praxis werden speziell externe Zertifikate aber eher auf allgemeine Kriterien geprüft, aktuelle Verschlüsselung, Gültigkeit, Aussteller und so weiter.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Hier sollten Sie eher so vorgehen: Legen Sie einen Ordner speziell für Webseiten/Zertifikate/Endpunkte an, sagen wir „websites“.

Abbildung 5: Elegant - Hostname in bestimmtem Ordner = überwachte Webseite.(Bild:  Lang | Checkmk)
Abbildung 5: Elegant - Hostname in bestimmtem Ordner = überwachte Webseite.
(Bild: Lang | Checkmk)

Dann benötigen Sie eine Regel für „Check certificates“, die folgende Werte setzt (siehe Abbildung 5):

  • „Service name / Name“: $HOSTNAME$
  • „Host address or name“: $HOSTNAME$
  • Condition „Folder“: „websites“

Alle anderen Werte können wie gewünscht gestaltet werden. Wenn Sie nun einen Host namens „www.ip-insider.de“ im Ordner „websites“ erstellen, greift der Check sofort und führt im Monitoring den entsprechenden Service auf. Standardmäßig lautet dieser dann „CERT www.ip-insider.de“, weil „CERT“ als Präfix gesetzt wird.

Freilich lässt sich an der Stelle auch mit weiteren Variablen arbeiten, insbesondere denen für Host-Alias und -Adresse. Am Ende bekommen Sie jedenfalls hübsche Übersichten, wenn Sie mit speziellen Ordnern arbeiten, ohne separate Ansichten und Filter zu erstellen (siehe Abbildung 6).

Moment! Schauen Sie nochmal genau auf Abbildung 6: Der Host „www.ip-insider.de“ steht hier auf CRIT, weil für die Regel nicht „$HOSTNAME$“ verwendet wurde, sondern „www.$HOSTNAME$.de“ – Sie können das ganz nach Belieben zusammenbauen.

Abbildung 6: Überwachte Webseiten im Überblick – durch simplen Filter auf den Host-Ordner.(Bild:  Lang | Checkmk)
Abbildung 6: Überwachte Webseiten im Überblick – durch simplen Filter auf den Host-Ordner.
(Bild: Lang | Checkmk)

check_cert als Solo-Tool

Wenn Sie lieber mit anderen System, Skripten oder spontan auf der Kommandozeile monitoren wollen, müssen Sie check_cert selbst kompilieren. Das funktioniert bisher verhältnismäßig problemlos. Nun, wenn Sie häufiger mal kompilieren wissen Sie, dass „verhältnismäßig“ nicht immer reibungslos bedeutet.

Im vorigen Artikel zu check_httpv2 finden Sie eine etwas ausführlichere Anleitung zum Kompilieren – da es mit check_cert aber genauso funktioniert, nur eben mit ausgetauschtem Paketnamen, hier nur die Kurzversion.

Installation mit Hilfe des Rust-Toolchain-Managers rustup unter Ubuntu 24.04 und auf dem Master-Branch von Checkmk:

sudo apt install rustup libssl-dev pkg-config gitrustup default stablemkdir ~/gitcd ~/gitgit clone https://github.com/Checkmk/checkmk.gitcd checkmk/packages/check-cert/cargo check --releasecargo build --releasecd ../../requirements/rust/site/target/release

Wenn Ihre Build-Umgebung aktuell ist, sollte es auch ohne rustup gehen – sollte ...

Checkmk wirbt zwar selbst für check_cert und check_httpv2 als eigenständige Tools, aber so lange der Build-Vorgang nicht stets aktuell dokumentiert wird, kann es immer zu kleinen Problemchen kommen.

Der Einsatz ist dann aber wieder einfach – wenn auch nicht ganz so einfach, wie innerhalb von Checkmk, wie dieses Beispiel zeigt:

./check-cert--url https://ip-insider.de \--port 443 \--not-after 3456000 1728000 \--max-validity 90 \--signature-algorithm 1.2.840.10045.4.3.2 \--pubkey-algorithm rsa \--pubkey-size 256

Zumindest zwei Angaben dürften hier nicht sofort klar sein: „not-after“ meint die von oben bekannte Restlaufzeit von 20/40 Tagen – allerdings angegeben in Sekunden. Und bei „signature-algorithm“ steht die OID für was? Wissen Sie nicht sofort? Natürlich für „ecdsa-with-SHA256“ … Es mag eine Geschmacksfrage sein, aber Tage und sprechende Namen würden auch den Kommandozeilenoptionen gut stehen!

Die sonstigen Optionen entsprechen aber der Checkmk-GUI.

Und hier noch das gekürzte Ergebnis im Terminal:

...Verification: OKSubject CN: ip-insider.deIssuer CN: R10Certificate signature algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11) but expected 1.2.840.10045.4.3.2 (!)Public key algorithm: RSAPublic key size: 2048 but expected 256 (!)Server certificate validity: 27 day(s) (warn/crit below 40 day(s)/20 day(s)) (!)Allowed validity: 89 day(s)

Durch die sehr strikte und bewusst auf Fehler gebürstete Konfiguration gäbe es hier nun einige Gründe für Warnungen, etwa Laufzeit und Schlüsselgröße. Auch das Signaturverfahren entspricht nicht dem gewünschten Algorithmus – schade, dass nur der Fund auch im Klartext angegeben wird und die Konfiguration bei der OID verbleibt.

Das neue Tool check_cert dürfte für viele Monitoringprojekte interessant sein. Wenn Checkmk das Duo check_cert und check_httpv2 noch etwas offensiver auch als Standalone-Tools vermarkten würde, wäre die Aufmerksamkeit aber vermutlich ungleich größer! Wenn man mal wünschen dürfte: Eigene Repos, stabile Build-Prozeduren, etwas Feintuning an den Cptionen und vielleicht sogar ein paar fertige Binaries für Nicht-Entwickler.

Alle Folgen des „Workshop: Monitoring mit Checkmk“ bei IP-Insider

(ID:50673825)