Icinga 2 Best Practice Teil 5: Autosign von Zertifikatsanfragen in verteilten Umgebungen

This entry is part 5 of 7 in the series Icinga 2 Best Practice

Ein jeder kennt das Problem, im Unternehmensnetz gibt es unterschiedliche netzwerkbezogene Sicherheitszonen, die mittels Perimeter voneinander getrennt sind. Für das Monitoring bedeutet dies im Idealfall, man stellt in jeder dieser Zonen einen Icinga-Satelliten bereit, der die von ihm ermittelten Ergebnisse an eine zentrale Instanz weiter meldet, den Icinga-Master. Damit ist gewährleistet, was Firewall-Admins berechtigterweise verlangen, lediglich Punkt-zu-Punkt-Verbindungen zu erlauben. Auch die Richtung des Verbindungsaufbaus ist mit Icinga 2 wählbar.
Setzt man zusätzlich auch Icinga 2 in der Ausprägung Agent ein, benötigt dieser ein signiertes Zertifikat um mit seinem jeweiligen Satelliten oder direkt mit dem Master zu kommunizieren. Im letzten Fall entstehen hieraus keine Probleme. In der Regel wird die CA, in einer Umgebung mit mehreren Satelliten auf dem Master betrieben. Bei lediglich einem Satelliten könnte die CA auch auf genau diesem Satelliten laufen, was jedoch Sicherheitsbedenken hervorruft. Ein Zertifikat aus einer niedrigen Sicherheitszone könnte verwendet werden, um mit einer höheren zu kommunizieren. Gleiches gilt natürlich auch bei der Benutzung lediglich einer CA, aber die Netzwerksicherheit soll ja dieses Risiko Minimieren.
Bleibt das Problem auf einem neuinstallierten Agenten mittels Autosigning ein beglaubigtes Zertifikat zu erhalten. Hier kann eine eigene CA auf jedem Satelliten Abhilfe schaffen. Der jeweilige Agent benötigt nun nur eine Verbindung zu seinem Satelliten um einen Request zu senden und keine Kommunikation zum Master. Wie wird nun dieses genau bewerkstelligt?

  • Erstellen einer CA auf dem Satelliten
  • Der Satellit bekommt ein Zertifikat signiert von seiner eigene CA
  • Der Satellit benötigt sein eigenes RootCA-Zertifikat und das vom Master
  • Der Master bekommt umgekehrt ebenfalls das RootCA vom Satelliten
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

kostenfreie TLS-Zertifikate mit Let's Encrypt

Let’s Encrypt hat seit gut einem Jahr die Testphase verlassen und verteilt fleißig Zertifikate – kostenfrei versteht sich. Wo anfangs in der Testphase “nur” wenige Millionen Zertifikate ausgegeben wurden, ist diese Zahl inzwischen kräftig gewachsen – Tendenz steigend. WordPress und andere Dienste setzen Let’s Encrypt in breitem Maße ein um das Internet ein bisschen besser (sicherer) zu machen.
Neben der reinen Absicherung der Verbindung hilft ein Zertifikat noch beim Ranking und dem lästigen Wegklicken von Sicherheitswarnungen bei selbstsignierten Zertifikaten, beispielsweise bei Testumgebungen. Chrome bemängelt seit der Version 39 auch die Sicherheit von normalen HTTP-Verbindungen und kennzeichnet diese als “nicht sicher”.
Die Zertifikate von Let’s Encrypt sind nicht besser oder schlechter als andere Zertifikate – nur kosten sie nichts und sind nicht so lange gültig – durch Automatismen zur Erneuerung eher ein Vorteil als ein Nachteil. Bei Let’s Encrypt gibt es keine Wildcard- oder EV-Zertifikate, wenn der Wunsch nach diesen besteht, greift man lieber zu kommerziellen Produkten. Auch wenn die Validierung mehr Sicherheiten bringen soll, als eine Domain-Validierung (hier wird ein Hash in einem vhost hinterlegt und von Let’s Encrypt geprüft), wird einem ein kommerzielles Produkt nahe gelegt.
Also eignen sich die Zertifikate für folgende Anwendungsfälle: Basisabsicherung von Diensten, wo sonst keine Verschlüsselung unbedingt notwendig wäre (z. B. WordPress-Blog), Absicherung von Staging-Systemen, Absicherung als kostenfreie Zugabe des Hosters, Absicherung von internen Diensten und zur Absicherung von privaten Websiten.
Aber wie kommt man nun zu den Zertifikaten?
Hier gibt es verschiedene Wege, allerdings gehe ich nur kurz auf die Command-Line basierte Beantragung ein. Dafür wird von Let’s Encrypt selbst der Certbot empfohlen, der bringt alles mit.
Nach dem Download / der Installation des Certbots (hier kommt es auf die Distribution an) kann dieser mittels dem einfachen Aufrufs

./certbot-auto

starten. Jetzt werden die weiteren Abhängigkeiten noch aus dem jeweiligen Paketmanager nachinstalliert. Ein Wizard startet und fragt welche Domains abgesichert werden sollen und ob ein automatischer (sicherer) redirect von HTTP auf HTTPS erfolgen soll (Hierzu werden Rewrite-Rules in der VHost-Config angelegt). Der Rest geht von alleine, eine CSR wird erstellt, ein vhost für die Domain-Validierung wird angelegt, es wird von extern gecheckt, ob der String im vhost erreichbar ist, Zertifikat wird ausgeteilt und gleich eingerichtet.
Achtung, nachdem der Wizard angestoßen wurde, wird mehrfach der Webserver neugestartet und Configfiles verändert. Für eine alternative Beantragung mit mehr Eigenverantwortung bitte die Hinweise zu certonly und webroot lesen.
Zertifikat nur 90 Tage gültig – was tun?
Die TLS-Zertifikate von Let’s Encrypt sind nur 90 Tage gültig. Die Beweggründe hierfür sind unterschiedlich. Aber aus meiner Sicht ist dies ein wesentlicher Sicherheitsvorteil. Damit es zu keinen Zertifikatsfehlern kommt, heißt es hier im richtigen Moment die Erneuerung der Zertifikate anzustoßen. Denn ein neues Zertifikat bekommt man erst kurz vor Ablauf des alten Zertifikates. An dieser Stelle komme ich an die vormals angesprochenen Automatismen zurück. So reicht es eigentlich täglich 1-2x einen Cron laufen zu lassen:

./certbot-auto renew

Durch dieses Kommando schaut der Certbot beim jeweiligen Lauf des Crons, ob das Zertifikat in Kürze abläuft. Wenn ja, wird ein neues Zertifikat beantragt und hinterlegt, wenn nicht meldet sich der Certbot nur mit einer kurzen Meldung im Log:

INFO:certbot.renewal:Cert not yet due for renewal

Auch hier sicherheitshalber nochmal der Hinweis, dass alle Abhängigkeiten beim renew aktualisiert werden (zu vermeiden mit dem –no-self-upgrade Flag). Desweiteren wird auch wieder ein vhost angelegt und der Webserver-Dienst durchgestartet.
Auch unsere Kunden mit komplexen Setups hinter Loadbalancern und HA-Clustern können von Let’s Encrypt profitieren – wir bauen hierzu die passende Lösung.
Freuen wir uns auf die nächsten Jahre, der wichtigste Schritt wurde bereits gemacht. Wer bei uns Kunde ist, kann schon heute von diesem tollen Service profitieren.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Weekly Snap: InGraph, Drobo + TimeCapsule backup & Certificates

15 – 19 August gave us a peek into the new graphing addon inGraph and one of our managed services projects while explaining certificates and backup with a Drobo – TimeCapsule combo.
From the Managed Services team, Sebastian shared a little on a hosting project at search engine marketing agency crealytics. Alongside Xen Hypervisor, PostgreSQL hot standby streaming replication with load balancing, automatic failover and online recovery, the set up also boasted a MongoDB replica set and load balanced, high availability Tomcat-Apache application server with Ruby support. All safeguarded by internal and external Icinga monitoring and an external backup server, ensuring crealytics could focus on their business free from IT worries.
Lennart then took us on a safari through the certificate jungle, clarifying the differences between PEM, DER, PKCS#7 / P7B, PKCS#12 / PFX and their conversion with the help of OpenSSL. In the meantime, Birger combined his network attached storage (NAS), Drobo with TimeCapsule for accelerated backups that also work on Apple’s new Lion operating system.
Most exciting of all, Gunnar announced inGraph, our new graphing addon for the display of monitoring metrics in Icinga and Nagios systems. Designed with scalability in mind, the tool is intended to replace NagiosGrapher and NETWAYS Grapher V2. Thanks to a python based backend, inGraph can access data collected by external applications with the help of a XML-RPC interface. Via templates, monitoring data can be displayed in various combinations as seen in a preview of inGraph integrated into Icinga’s new web interface. The development team is currently ironing out features and documentation, in preparation of the release planned for the upcoming monitoring conference.

Safari durch den Zertifikatsdschungel

PEM ist das mt Abstand meistgenutze Format. Es handelt sich hierbei um Base64 kodierte ASCII-Dateien, die ein “—–BEGIN CERTIFICATE—–” und “—–END CERTIFICATE Statement beinhalten. Ülicherweise werden sie mit einem Suffix wie .pem, .crt, .cer oder .key versehen.
Serverzertifikate, Zwischenzertifikate und private Schlüssel können alle im PEM-Format vorliegen oder in dieses konvertiert werden. Apache oder ähnliche Server benutzen das PEM-Format. Mehrere PEM Zertifikate und auch der private Schlüssel können in einer Datei zusammengefaßt werden. Aber die meisten Plattformen, wie z.B. der Apache erwarten Zertifiakte und privaten Schlüssel in unterschiedlichen Dateien.
DER ist ein binäres Format. Es hat manchmal .der als Suffix, kann aber auch auf .cer enden. Um herauszufinden, ob das vorligende Zertifikat im PEM- oder DER-Format vorliegt, ist einfach zu prüfen, ob die oben beschriebenen Statements vorkommen. Dieses kann man auch durch einfaches öffnen in einem Texteditor ermitteln.
Alle Zertifikatesformen und auch der private Schlüssel können im DER-Format kodiert werden. DER wird typischerweise auf JAVA-Plattformen eingesetzt, da der dortige SSL-Converter nur Zertifikate im DER-Format konvertiert.
PKCS#7 bzw. P7B sind üblicherweise in Base64 kodiert und benutzen ein Suffix, wie .p7b oder .p7c. P7B-Zertifikate sind an den beiden Statements “—–BEGIN PKCS7—–” und “—–END PKCS7—–” zu erkennen. Eine P7B Datei beinhaltet nur das Zertifikat und das Zertifikat der signierenden CA, nicht den privaten Schlüssel. Viele Plattformen unterstützen dieses Format, z.B. Tomcat oder Microsoft Windows.
PKCS#12 bzw. PFX ist ein binärkodiertes Format. Das Server-Zertifikat, jedes Zwischenzertifikat und der private Schlüssel werden in einer Datei abgelgt. PFX-Dateien werden typischerweise auf Windows-Plattformen zum im- bzw. exportieren verwendet und enden üblicherweise auf .pfx oder .p12.
Konvertierung mit OpenSSL
PEM -> PKCS12: openssl pkcs12 -export -out certificate.pfx -inkey private.key -in certificate.crt -certfile CACert.crt
PEM -> DER: openssl x509 -outform der -in certificate.pem -out certificate.der
PEM -> P7B: openssl crl2pkcs7 –nocrl -in certificate.cer -out certificate.p7b -certfile CACert.cer
DER -> PEM: openssl x509 -inform der -in certificate.cer -out certificate.pem
P7B -> PEM: openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
P7B -> PFX: openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer; openssl pkcs12 -export -in certificate.cer -inkey private.key -out certificate.pfx -certfile CACert.cer
PFX -> PEM: openssl pkcs12 -in certificate.pfx -out certifikate.cer -nodes
Bei der Konvertierung von PFX nach PEM packt openssl alle Zertifikate und den privaten Schlüssel in eine Datei. Es ist jedoch leicht möglich die jeweiligen Zertifikate, sowie den privaten Schlüssel mit den BEGIN- und END-Statements per Copy’n’Paste in eigene Datei zu kopieren und zu speichern.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.