Let’s Encrypt fürs Intranet
Seit 2016 gibt es keine Ausrede mehr für fehlende Verschlüsselung im Web: seitdem stellt die Let’s Encrypt-Initiative jedem kostenlos Zertifikate für eigene Domains aus — und das mittlerweile schon über eine Milliarde mal.
Entsprechend garstig reagieren Browser heute, wenn sie eine Seite ohne Verschlüsselung sehen: sie weisen mit immer drastischeren Fehlermeldungen darauf hin, dass sie nicht sicher sind.
Eigentlich alles richtig. Doch es gibt ein Umfeld, in dem “echte” Zertifikate noch selten anzutreffen sind: das Intranet. Hier wird oft noch mit selbst-signierten Zertifikaten verschlüsselt (die Browser und andere Tools nicht ohne Weiteres akzeptieren), oder gar nicht. Nur wenige Unternehmen beißen in den sauren Apfel, und kaufen Zertifikate von anderen CAs, welche die Überprüfung manuell z.B. über Handelsregisterauszüge durchführen, und sich das nicht selten vierstellig im Jahr vergüten lassen.
Das ACME-Protokoll
Voraussetzung für ein Let’s Encrypt-Zertifikat ist, dass wir beweisen können, dass uns die Domain gehört, für die wir gerade ein Zertifikat anfragen. Andernfalls könnte sich sonst schließlich jeder ein gültiges Zertifikat für z.B. Google oder Microsoft ausstellen lassen. Um das automatisiert zu überprüfen, gibt es das ACME-Protokoll (nein, damit ist nicht der Haus- und Hoflieferant des Kojoten aus Road-Runner gemeint, sondern die “Automated Certificate Management Environment”).
Meistens funktioniert es so:
- Die Besitzerin der Seite fragt das Zertifikat an
- ACME fordert sie dazu auf, einen zufälligen Text zu signieren und in einer Datei öffentlich abrufbar unter der Domain bereitzustellen
- Dann ruft Let’s Encrypt die Datei ab — passt sie, darf die Besitzerin ein Zertifikat für diese Domain abfragen
Der Nachteil dieses Verfahrens ist, dass es nur funktioniert, wenn die Domain öffentlich im Internet erreichbar ist. Die Idee eines Intranets ist aber genau das Gegenteil: es soll nur im Unternehmen, oder über ein VPN aufrufbar sein.
Um dies zu umschiffen, gibt es eine alternative Methode: die DNS-Challenge.
DNS-Challenge
Nochmal einen Schritt zurück: Let’s Encrypt will sichergehen, dass uns die Domain gehört, für die wir gerade ein Zertifikat anfordern. Ein Webserver ist dafür eigentlich nicht notwendig — es reicht, wenn wir beweisen können, Kontrolle über den DNS-Baum zu haben (DNS kurz: das System, welches aus Domain-Namen IP-Adressen macht).
Bei der DNS-Challenge verlangt ACME, dass wir einen neuen DNS-Eintrag an der Domain hinterlegen, um die es gerade geht. Der Eintrag hat immer den Namen _acme-challenge, der Wert ist zufällig. Für die Domain “intern.cofinpro.de” sieht das dann so aus:
- — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Please deploy a DNS TXT record under the name
_acme-challenge.intern.cofinpro.de with the following value:DxvmioGbvyABF_yv-Ly76jJg7j8nvbBHVkQ9tp96M0EBefore continuing, verify the record is deployed.
- — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Nun können wir in der Admin-Konsole beim Hoster der Domain den Eintrag vornehmen und den Vorgang abschließen. Voilà, ein Zertifikat für eine nicht im Internet erreichbare Domain!
Dies lässt sich noch weitertreiben: wenn viele verschiedene Domains im Spiel sind, ist es praktischer, ein Wildcard-Zertifikat zu verwenden, statt eines für jede Domain. Solche Zertifikate sind z.B. auf *.intern.cofinpro.de ausgestellt und decken damit alle Domains unterhalb von intern.cofinpro.de ab (z.B. mail.intern.cofinpro.de, www.intern.cofinpro.de, webapp.intern.cofinpro.de). Wildcard-Domains sind momentan der DNS-Challenge vorbehalten — dafür erlaubt Let’s Encrypt sogar mehrere Wildcard-Domains pro Zertifikat. Die meisten kommerziellen Hoster zieren sich hier, und möchten lieber ein Zertifikat pro Wildcard verkaufen.
Zertifikate automatisch verlängern
Zertifikate von Let’s Encrypt haben einen Haken: sie sind nur 90 Tage gültig. Deshalb sollte man sich schon beim Ausrollen um die Verlängerung Gedanken machen und sie automatisieren. Hier wird es bei der DNS-Challenge ein wenig knifflig: der DNS-Anbieter, bei dem die Domain liegt, muss die Einträge sehr zügig vornehmen (am besten in unter 5 Minuten — manche lassen sich aber bis zu 24 Stunden Zeit), und muss eine API bereitstellen, die von einem Skript angesprochen werden kann. Let’s Encrypt’s eigenes Skript “certbot” unterstützt hier nur wenige große Anbieter (z.B. Amazons Route 53, Cloudflare, Digitalocean), oder offene und selbstgehostete DNS-Server wie Bind. Mehr Auswahl bietet das alternative Skript “Acme.sh”.
DNS-Delegation
Was, wenn der Anbieter des eigenen Unternehmens nicht dabei ist? Oder dem Admin nicht wohl dabei ist, die Zugangsdaten zum DNS-Provider rauszugeben und auf einem Server offen liegen zu lassen? Auch hierfür gibt es noch einen Trick: es ist möglich, die _acme-challenge-Domain (und nur diese) bei einem anderen Provider zu hosten, als die Hauptdomain. Hierfür delegiert der Domain-Server der Hauptdomain über einen NS-Record (Name Server Resource Record — ab hier ist ein anderer Server zuständig) auf den “Spezial-DNS” für die Challenge-Domain. So behält der Admin die volle Kontrolle und wir haben freie Hand bei der Auswahl eines LE-freundlichen DNS-Hosters.
Verteilen der Zertifikate
Nachdem wir ein Zertifikat für unsere interne Domain haben, bleibt eigentlich nur noch eins zu tun: es zu verteilen. Auch das sollte automatisiert sein, damit nach Ablauf der 90 Tage niemand vor Fehlermeldungen steht. Certbot und Acme.sh bieten hierfür Hooks an: Das sind Shell-Skripte, die nach dem Erneuern eines Zertifikats mit allen wichtigen Infos (Domain, Pfad zum Zertifikat und Key) aufgerufen werden. Hierüber lässt sich das neue Zertifikat z.B. per SCP auf alle Server kopieren.
Noch eleganter ist das Verteilen über Tools wie Puppet, Chef oder Ansible, die dann den Neustart der Dienste direkt mit erledigen können.
Zusammenfassung
Auch wenn es ein bisschen schwieriger als für öffentlich erreichbare Server ist: Let’s Encrypt-Zertifikate für das Intranet ist machbar. Über die DNS-Challenge sind auch heißbegehrte Wildcard-Zertifikate möglich, was das Verfahren insbesondere für Umgebungen mit vielen internen Systemen attraktiv macht.
Hierfür sind ein paar Klimmzüge notwendig:
- ein DNS-Hoster mit schneller Antwortzeit und API-Zugang
- und/oder das Delegieren der Challenge-Domain an einen anderen Hoster
- Automatisieren der Verlängerung und der Verteilung von Zertifikaten
Im Gegenzug entfällt das lästige Hantieren mit selbstsignierten Zertifikaten, hausinternen CAs und Fehlermeldungen bei all den Tools, die hiermit ihre Probleme haben.
