12. Januar 2021, 22:20
Lesezeit: ca. 5 Min

Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.

Monitoring von Zertifikaten

Jeder kennt die Warnung bei Besuch einer Internetseite mit abgelaufenem Zertifikat. Einmal im Monat stolpere ich mindestens über eine oder erhalte Tickets mit Nachfragen, was zu tun sei. “Nichts” antworte ich meist. “Der Fehler liegt bei der Gegenseite”. An dieser Stelle mein spezieller Dank an die Betreiber oder Admins solcher Seiten für die zusätzliche Arbeit.

Der naheliegende Lösungsvorschlag zur Vermeidung solcher Peinlichkeiten: Eine Software oder Dienst mit periodischer Überprüfung und rechtzeitiger Benachrichtigung. Klingt einfach, funktioniert aber leider nicht immer.

Hier eine Übersicht der letzten Jahre mit nicht rechtzeitig verlängerten Zertifikaten:

  • 2020/06 Sectigo Root-Cert1
  • 2020/02 Microsoft Teams2
  • 2019/10 Apple App-Store3
  • 2019/08 Twitter4
  • 2019/05 Mozilla Add-Ons5
  • 2018/04 Microsoft Azure6

Und das sind nur die Fälle großer Tech-Konzerne. Die vielen kleinen Websites bleiben unter dem Radar. Was also läuft da schief?

Nicht verlängerte Zertifikate sind keine Kleinigkeit und betreffen nicht nur Internetseiten. Viele Apps auf mobilen Endgeräten hören auf zu funktionieren wenn die JSON-Gegenstellen7 nicht mehr erreichbar sind. Und mal ehrlich: Die meisten User klicken die Warnungen weg, mechanisch, ohne zu wissen, auf was sie geklickt haben. Die böse Überraschung kommt später, wenn unter den vielen weggeklickten Warnungen auch eine zufällig durchgereichte Malware war. Für etwas Zahlenmaterial betrachten wir die Folgen eines Vorfalles für ein Unternehmen.

Im weltweit operierenden TUI-Konzern entstehen an einem Arbeitstag bis zu 20.000 Videokonferenzen und 250.000 Chat-Nachrichten8. Der Ausfall von Microsoft Teams am 04.02.2020 zwischen 15 und 18 Uhr hat demnach 7.500 Konferenzen behindert und im mildesten Fall Zeitpläne durcheinander gebracht. Im schlimmsten Fall konnten wichtige Entscheidungen nicht getroffen und Fristen nicht eingehalten werden. Eine Anzahl der verärgerten Geschäftspartner, Zulieferer oder Kunden existiert leider nicht.

Das 20179 gestartete Teams wird jährlich mit einem neuen Zertifikat bedacht. Auf bislang zwei erfolgreiche Verlängerungen folgte eine verpasste. Auch ohne Statistik-Studium eine miserable Quote. Es ist nicht so, dass eine Zertifikatsverlängerung unerwartet aus dem heiteren Himmel fällt.

Liegt der Erfolg einer Maßnahme nahe der Normalverteilung10 kann diese ausgelassen werden. Der Zufall oder eine Horde Affen arbeiten genauso zuverlässig.

Warum Zertifikats-Verlängerungen scheitern

Bei meiner Recherche im Netz habe ich leider keine Quelle finden können, die mehr zu den beitragenden Faktoren sagen könnte. Ohne Anspruch auf Vollständigkeit und Richtigkeit und anhand meiner persönlichen Erfahrungen habe ich diese Liste erstellt:

a) Führungsversagen: Niemand fühlt sich verantwortlich
b) Organisationsversagen: Fehlende Prozesse und Übersicht aller Zertifikate einer Organisation.
c) Schlampigkeit bei vorhandenem Monitoring.
d) Fahrlässigkeit durch fehlendes Monitoring. Blindes Vertrauen in Auto-Renewal Prozesse.
e) Absichtliche Handlung, Sabotage

Die auffällige Gemeinsamkeit: Es sind alles nicht-technische Faktoren.

Das klingt ernüchternd, aber nicht hoffnungslos. Und als Geheimwaffe hätte ich da etwas, was ich als Softwareentwickler seit den 90ern nutze: Eine Quellcode-Versionsverwaltung11. Bevor ich zeige wie ich dieses Problem löse bitte immer die allgemeingültige Lebensweisheit im Hinterkopf behalten:

Schlechte Führung oder miserables Management können auch mit der besten Software nicht besser werden.

Git + Gitea + Monit

Letztes Jahr habe ich hier im Blog Prometheus12 und Grafana13 als Werkzeuge aus meinem Monitoring-Stack vorgestellt. Heute folgt Monit14 zum regelmäßigen Überprüfen von Websites, APIs und Zertifikaten.

Warum Monit? Erstens sind Abfragen und Regeln wunderbar auf verschiedene Konfigurationsdateien aufteilbar. Zweitens ist es mächtig. Drittens ist es in der formalen Beschreibung von Regeln dank eines BASIC-artigen15 Syntax simpel. Das ist zum Beispiel die Regel zum Überwachen des Zertifikates dieses Blogs:

check host blog.jakobs.systems with address blog.jakobs.systems
  if failed 
	port 443 
	protocol https 
	certificate valid > 5 days
  then alert

Die Magie liegt im Zusammenspiel von Monit mit git16 und Gitea17. Alle Monit-Instanzen beziehen Ihre Konfiguration automatisiert aus einem git Repository18. Das Management und die Skalierung erfolgen über die Web-Oberflächen von Gitea und benötigen keine Programmierkenntisse. Angenehmer Nebenaspekt: Eine vollständige Dokumentation fällt als “Nebenprodukt” ab, da ich diese in Markdown19 mit in das Repository packe.

Screenshot Gitea

Informationen zu Zertifikaten einer Organisation haben endlich einen von allen zugänglichen Platz gefunden. Änderungen bleiben nicht an Wenigen hängen. Jeder Webentwickler kann z.B. neue Hosts aufnehmen oder Änderungen vornehmen. Ein “Kaputt-Machen” ist kaum möglich da einerseits jede Änderung wieder rückgängig gemacht werden kann. Anderseits fallen grobe Schnitzer im gegenseitigen Peer-Review von Pull-Requests20 sofort auf. Sollte eine fehlerhafte Konfigurationsdatei Ihren Weg auf eine Monit-Instanz finden, so wird mir das sofort gemeldet und ich kann immer noch einschreiten.

Die Kombination aus Monit, git und Gitea ermöglicht ein lebendes, skalierbares System mit einem kontinuierlichen Verbesserungsprozess.

Resilienz

Ohne ein paar Worte zur Resilienz21 geht es nicht. Mir begegnen leider immer Netzwerke, wo von einem internen Host aus die komplette IT Infrastruktur überwacht wird. Kann man machen, nur schafft das unnötige und selbstgemachte Probleme. Kommen die typischen “Single Points of Failure”22 in Gestalt zentraler Mailserver, Firewalls oder Switches noch hinzu, sollte gehandelt werden.

Stromnetze werden erfolgreich mit der (n-1)-Regel23 betrieben. Diese besagt, dass es zu jedem Element in einem System mindestens ein redundantes Ersatzelement geben muss. Freileitungen zum Beispiel verfügen mindestens über zwei Leitsysteme, die jeweils nur mit 50% Last betrieben werden. Kommt es zur Störung eines Leitsystems kann das Verbliebene schnell 100% an Last übernehmen.

Screenshot von 3 Monit-Instanzen

Diese Regel erhöht die Resilienz auch in der IT. Im Screenshot sichtbar sind meine drei quer in Deutschland verteilten Monit-Instanzen (Rechenzentrum, Office, Homeoffice) an unterschiedlichen ISPs (Anexia-Backbone, Vodafone, Telekom) mit denen ich nicht nur meine eigenen Hosts und Zertifikate im Blick halte sondern auch die meiner Kunden.

Es gibt Gründe, warum Monitoring nicht gleich Monitoring ist.

Ich helfe gerne mit meinem Know-How.
Nachhaltig, transparent, fair und mit Open-Source.

In diesem Sinne,
Tomas Jakobs


  1. https://www.heise.de/news/AddTrust-Probleme-durch-abgelaufenes-Root-Zertifkat-4771717.html ↩︎

  2. https://www.heise.de/newsticker/meldung/Microsoft-Teams-Ausfall-wegen-Zertifikatsablauf-4652527.html ↩︎

  3. https://www.heise.de/mac-and-i/meldung/Abgelaufene-Sicherheitszertifikate-Wie-man-jetzt-neue-macOS-Installer-findet-4569853.html ↩︎

  4. https://www.pcworld.com/article/201980/article.html ↩︎

  5. https://www.heise.de/newsticker/meldung/Zertifikat-abgelaufen-Firefox-deaktiviert-Add-ons-4413170.html ↩︎

  6. https://www.borncity.com/blog/2018/04/18/zertifikatsprobleme-bei-microsoft-seiten/ ↩︎

  7. https://de.wikipedia.org/wiki/JavaScript_Object_Notation ↩︎

  8. https://www.tuigroup.com/en-en/media/stories/2021/2021-01-07-ms-teams-and-corona ↩︎

  9. https://en.wikipedia.org/wiki/Microsoft_Teams ↩︎

  10. https://de.wikipedia.org/wiki/Normalverteilung ↩︎

  11. https://de.wikipedia.org/wiki/Versionsverwaltung ↩︎

  12. https://blog.jakobs.systems/blog/20201025-monitoring-prometheus/ ↩︎

  13. https://grafana.com/ ↩︎

  14. https://www.mmonit.com/monit ↩︎

  15. https://de.wikipedia.org/wiki/BASIC ↩︎

  16. https://de.wikipedia.org/wiki/Git ↩︎

  17. https://gitea.io/en-us/ ↩︎

  18. https://en.wikipedia.org/wiki/Repository_(version_control) ↩︎

  19. https://de.wikipedia.org/wiki/Markdown ↩︎

  20. https://de.wikipedia.org/wiki/Pull_Request ↩︎

  21. https://de.wikipedia.org/wiki/Resilienz-Management ↩︎

  22. https://de.wikipedia.org/wiki/Single_Point_of_Failure ↩︎

  23. https://de.wikipedia.org/wiki/(n_%E2%80%93_1)-Regel ↩︎

© 2024 Tomas Jakobs - Impressum und Datenschutzhinweis

Unterstütze diesen Blog - Spende einen Kaffee