Obwohl das Betreiben einer eigenen CA (Certification Authority) in den meisten Fällen weder notwendig noch ratsam ist, gibt es auch Ausnahmen: Wenn z.B. Unternehmens-interne Dienste abgesichert werden sollen, kann es einfacher / sicherer oder sogar erforderlich sein, selbst signierte Zertifikate einzusetzen. Während meiner Beschäftigung bei der ADITO Software GmbH habe ich ein Tool zur Verwaltung von X.509-Zertifikaten im Unternehmensumfeld entwickelt. Nachdem erste Tests und das Aufsetzen der Produktivumgebung erfolgreich waren, galt es nun, das Root-Zertifikat der eigenen CA auf die Windows- und Linuxrechner der Mitarbeiter zu verteilen.
Spätestens seit 2013 gibt es Initiativen, die das XMPP-Netzwerk durch Transportverschlüsselung sicherer machen wollen. Mittlerweile unterstützen fast alle öffentlichen XMPP-Server zumindest optional Transportverschlüsselung via TLS oder SSL. Leider wird das Thema nur in den wenigsten Fällen wirklich ernst genommen - und das mache ich u.A. daran fest: In viel zu vielen Fällen können wir bei der Server-to-Server-Kommunikation folgendes finden:
Verwendung von selbst signierten Zertifikaten Defekte / ungültige Zertifikatskonfigurationen (fehlendes Intermediate-Cert, abgelaufene Zertifikate, …) Tolerierung unverschlüsselter Verbindungen Vor allem gegen den letzten Punkt muss unbedingt etwas unternommen werden.
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit.
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert.
Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:
Let’s Encrypt nutzt ein Protokoll namens “ACME” zur Kommunikation mit den CA-Servern. Ich habe den Referenz-ACME-Client “Certbot” von LE genutzt - um den soll es hier gehen.