Das grüne Schloss für Dienste, die niemand sieht

Du kennst diese Seite. Du tippst die Adresse deines Routers ein, oder die eines kleinen Servers im Keller, irgendwas mit 192.168.x.x, und statt der Anmeldung kommt eine ganzseitige Warnung: „Dies ist keine sichere Verbindung.“ Du klickst auf „Erweitert“, dann auf „Weiter zu 192.168.x.x (unsicher)“, und alles läuft. Beim nächsten Mal klickst du schneller. Irgendwann klickst du, ohne hinzusehen.

Und genau da liegt das Problem. Die Warnung ist für den einen Tag gedacht, an dem wirklich jemand zwischen dir und dem Gerät sitzt. Wer sie täglich wegklickt, liest sie an diesem Tag auch nicht mehr.

Als ich mein Homelab aufgebaut habe, also die kleine Serverlandschaft bei mir zu Hause, um die es in dieser Serie geht, wollte ich mir diese Gewohnheit abgewöhnen. Jeder Dienst sollte ein echtes grünes Schloss im Browser haben. Der Haken: Keiner dieser Dienste ist aus dem Internet erreichbar, und das ist normalerweise die Voraussetzung für ein solches Schloss. Wie es trotzdem klappt, erzähle ich hier, von ganz vorne.

Namen und Hausnummern

Jedes Gerät im Netz hat eine Adresse aus Zahlen, die IP-Adresse. Sie funktioniert wie eine Hausnummer: Dorthin werden die Datenpakete zugestellt. Die Nummern mit 192.168 vorne gelten nur in deinem Heimnetz, ungefähr so wie eine Zimmernummer im Hotel, mit der draußen auf der Straße niemand etwas anfangen kann.

Weil sich niemand Nummern merken will, gibt es Namen. paperless.home.example ist so ein Domainname. Der hintere Teil gehört zu einer Domain, die ich gemietet habe, und davor darf ich mir beliebig viele Namen ausdenken. (home.example ist hier im Blog ein Platzhalter, meine echte Domain lautet anders.)

Das Übersetzen von Namen in Nummern erledigt das DNS, das Domain Name System. Stell es dir als Telefonbuch vor: Du fragst nach einem Namen, ein DNS-Server schlägt nach und nennt dir die Nummer. Wichtig für später ist, dass es mehr als ein Telefonbuch gibt. Das öffentliche gehört dem Internet; die Einträge für meine Domain führt dort Hetzner, ein Hoster, bei dem ich sie verwalte. Daneben kann jedes Netz ein eigenes, kleines Telefonbuch haben, das nur drinnen gilt.

Ein Ausweis für den Server

Jetzt zum Schloss. Lädt dein Browser eine Seite über HTTPS, passieren zwei Dinge. Die Verbindung wird verschlüsselt, damit unterwegs niemand mitlesen kann. Und der Server muss sich ausweisen, damit du sicher bist, wirklich mit paperless.home.example zu sprechen und nicht mit jemandem, der sich dazwischengeschoben hat.

Dieser Ausweis heißt Zertifikat. Darauf steht, für welche Namen er gilt, bis wann, und wer ihn unterschrieben hat. Unterschreiben darf eine Zertifizierungsstelle, und dein Browser bringt eine Liste der Stellen mit, denen er vertraut. Hat sich ein Server seinen Ausweis selbst unterschrieben, ist das wie ein am Küchentisch gebastelter Personalausweis. Der Inhalt mag stimmen, nur prüfen kann ihn niemand.

Damit ist die Warnung vom Anfang erklärt. Dein Router zeigt entweder so einen selbst gebastelten Ausweis, oder einen, auf dem ein anderer Name steht als der, den du eingetippt hast. Für eine nackte Hausnummer wie 192.168.x.x stellt dir keine öffentliche Stelle einen Ausweis aus, denn dieselbe Nummer gibt es in Millionen Haushalten. Ein Domainname dagegen gehört genau einem.

Meine Zertifizierungsstelle ist Let’s Encrypt. Sie stellt Zertifikate kostenlos und vollautomatisch aus, jedes für 90 Tage. Bevor sie unterschreibt, will sie allerdings wissen, ob dir der Name wirklich gehört.

Der Prüfer, der nicht klingeln kann

Der übliche Beweis heißt HTTP-01-Challenge, wobei Challenge einfach Prüfaufgabe bedeutet. Let’s Encrypt gibt dir ein Stück Text, du legst es auf deinem Webserver ab, und Let’s Encrypt holt es von außen dort ab. Wer unter dem Namen antwortet, dem gehört er. Praktisch, nur muss dein Server dafür aus dem Internet erreichbar sein.

Meiner ist das nicht. An meinem Router ist keine Tür nach drinnen offen, kein einziger Port, wie das im Fachjargon heißt. Alle meine Geräte reden über NetBird miteinander, ein privates, verschlüsseltes Netz, das sich über das normale Internet legt; wie das funktioniert, steht in Teil 2. Für Let’s Encrypt heißt das: Der Prüfer steht vor der Tür und findet keine Klingel.

Zum Glück gibt es einen zweiten Weg, die DNS-01-Challenge. Dabei klopft Let’s Encrypt gar nicht am Server an. Es schaut ins öffentliche Telefonbuch. Ich soll dort unter dem Namen _acme-challenge.home.example einen TXT-Eintrag hinterlegen, eine Zeile freien Text, die den Prüftext enthält. Wer die Einträge einer Domain ändern kann, dem gehört sie, so die Logik. Mein Server muss dafür nur mit Hetzner reden können. Das geht über deren API, also die Schnittstelle, über die Programme statt Menschen Einträge ändern, und als Schlüssel dient ein API-Token.

Die Arbeit erledigt bei mir der Proxy, ein Programm, zu dem ich weiter unten komme. Das Bild zeigt, wer dabei wen fragt.

Alle Verbindungen gehen dabei von meinem Proxy nach draußen, hereinkommen muss niemand. Der orange Schritt ist der einzige, der mehr braucht als Internetzugang, nämlich den Schlüssel zu meinen DNS-Einträgen. Das Ganze dauert ein bis drei Minuten, das meiste davon Warten: Der neue Eintrag muss erst auf allen DNS-Servern von Hetzner angekommen sein, bevor Let’s Encrypt nachsieht.

Ein Sternchen für alle

Wenn ich schon beweise, dass mir die Einträge der ganzen Domain gehören, kann ich auch mehr verlangen als einen einzelnen Namen. Ein Wildcard-Zertifikat gilt für *.home.example, und das Sternchen steht für jeden beliebigen Namen an dieser Stelle: paperless, nextcloud, immich, und alles, was ich morgen noch aufsetze. Let’s Encrypt stellt solche Wildcards übrigens nur nach einer Prüfung im DNS aus. Mein Umweg ist also zugleich der einzige Weg dorthin.

Das Sternchen gilt allerdings genau für eine Ebene. *.home.example passt auf paperless.home.example, aber nicht auf home.example selbst, wo meine Startseite liegt. Deshalb trägt mein Zertifikat noch einen zweiten Wildcard für die Domain darüber, und der deckt die Startseite ab. Den Namen der Startseite zusätzlich in denselben Antrag zu schreiben, lehnt Let’s Encrypt übrigens ab, weil der Wildcard ihn schon abdeckt.

Zwei Telefonbücher

Der Browser bekäme jetzt einen gültigen Ausweis gezeigt. Erst einmal muss er aber ankommen, und dafür braucht er zu paperless.home.example eine Adresse.

Die liefert AdGuard Home, ein DNS-Server in meinem Netz, der nebenbei Werbung und Tracker herausfiltert. In AdGuard steht für alle meine Dienste ein einziger Eintrag, eine sogenannte Umschreibung: Jeder Name, der auf .home.example endet, wohnt bei der Adresse des Proxys. NetBird sorgt dafür, dass meine Geräte genau dieses Telefonbuch fragen. Ob ich nach Paperless, Nextcloud oder Immich frage, die Antwort ist immer dieselbe. Eine Regel dazu habe ich mir teuer erkauft: Die Anweisung „frag AdGuard“ darf nie an alle Geräte gleichzeitig gehen. Die Geschichte dazu steht in Teil 2.

Und im öffentlichen Telefonbuch? Da steht, ehrlich gesagt, derselbe Wildcard mit derselben Adresse. Das klingt erst einmal nach einem Leck, ist aber harmlos. Es ist die Adresse des Proxys im NetBird-Netz, und solche Adressen leitet das Internet nirgendwohin, wie eine Zimmernummer ohne Hotel. Einzelne Dienstnamen stehen dort gar nicht, nur das Sternchen.

Fachleute nennen so etwas Split DNS, ein Telefonbuch für drinnen und eines für draußen. Bei mir unterscheiden sich die beiden weniger in den Antworten als darin, wer mit ihnen etwas anfangen kann. Das Bild stellt beide Seiten nebeneinander.

Links siehst du den Weg, den jede Anfrage von mir nimmt. Rechts das, was die Welt von meinen Diensten mitbekommt, und das ist erfreulich wenig.

Ein Pförtner, ein Ausweis

Alle Namen führen zur selben Adresse, also muss dort jemand die Besucher verteilen. Das macht Nginx Proxy Manager, ein Reverse Proxy, ab jetzt einfach der Proxy. Stell ihn dir als Pförtner vor: Er nimmt jede Anfrage an, zeigt das Wildcard-Zertifikat vor, liest, zu welchem Namen sie will, und reicht sie an den richtigen Dienst weiter.

Für einen neuen Dienst lege ich im Proxy einen Eintrag an: Name, Ziel, Port, dazu das vorhandene Zertifikat. Am DNS ändere ich nichts, ein neues Zertifikat brauche ich nicht. Als Ziel trage ich immer die NetBird-Adresse des Dienstes ein, keinen Rechnernamen. Damit läuft auch der Weg vom Proxy zum Dienst verschlüsselt, und ich umgehe eine Falle, die mich auf einem anderen Proxy sporadische 502-Fehler gekostet hat. Die steht in der Geschichte über ntfy.

Bleibt die Frage, was nach 90 Tagen passiert. Nichts, um das ich mich kümmern müsste. Der Proxy erneuert das Zertifikat von selbst, etwa 30 Tage vor Ablauf, und spielt dabei die ganze Prüfung mit dem TXT-Eintrag noch einmal durch. Nachzählen kann man das im öffentlichen Logbuch, zu dem ich gleich komme: Mitte Februar, Mitte April, Mitte Juni, Mitte August, alle 60 Tage ein neues. Das aktuelle stammt von Anfang September und läuft Anfang Dezember ab. Die nächste Erneuerung steht also in diesen Tagen an, und ich werde davon nichts merken.

Das Logbuch, in dem alles steht

Jedes Zertifikat einer öffentlichen Stelle landet in öffentlichen Logbüchern, den Certificate-Transparency-Logs. Sie sollen auffallen lassen, wenn eine Stelle einen Ausweis für einen Namen ausstellt, der ihr nicht zusteht, und gängige Browser verlangen inzwischen, dass ein Zertifikat dort eingetragen ist. Durchsuchen kann sie jeder, zum Beispiel auf der Website crt.sh.

Für ein Homelab, das sich nicht zeigen will, ist das erst einmal unangenehm. Hätte ich für jeden Dienst ein eigenes Zertifikat, stünde dort meine komplette Dienstliste mit Datum. Mit dem Wildcard steht dort nur das Sternchen, ein Grund mehr für ihn.

Ganz sauber ist mein Eintrag trotzdem nicht. Beim Nachsehen fand ich auch ein Einzelzertifikat für einen einzigen Dienst, mit vollem Namen. Was einmal im Logbuch steht, bleibt dort. Schlimm ist das nicht, ein Name allein öffnet keine Tür. Es erinnert aber daran, dass „intern“ nicht dasselbe ist wie „unsichtbar“.

Wo es gehakt hat

Bleiben zwei Stolpersteine, über die ich unterwegs gefallen bin.

Aus der Praxis: Im September wollte ich per Skript einen DNS-Eintrag für einen neuen Server anlegen. Die alte Schnittstelle unter dns.hetzner.com leitete aber nur noch auf Hetzners neue Konsole um. Die DNS-Verwaltung ist in die allgemeine Cloud-API gewandert, nach api.hetzner.cloud/v1/zones/<id>/rrsets, mit derselben Anmeldung per Authorization: Bearer wie für Server. Auch das Ändern funktioniert anders: Einen bestehenden Eintrag überschreibt man nicht per PUT, sondern mit einem POST auf …/rrsets/<name>/<typ>/actions/set_records. Für das Zertifikat war ich zum Glück vorbereitet: Der Proxy kennt beide APIs, und mein Hilfsskript nimmt standardmäßig die neue.

Der zweite Stolperstein liegt eine Etage höher. Auch die Domain über home.example hat im öffentlichen Telefonbuch einen Wildcard-Eintrag, und der zeigt auf einen ganz anderen Server im Internet. Solange ein Gerät AdGuard fragt und ich den Namen richtig tippe, merke ich davon nichts. Vergesse ich aber das home im Namen, oder fragt ein Gerät einen öffentlichen DNS-Server nach einem Namen, den nur mein internes Telefonbuch kennt, landet es irgendwo anders. Dann ist sie wieder da, die Warnung vom Anfang, oder eine Passwortabfrage, die nie passt. Wie mich genau das bei SSH eine Weile gekostet hat, steht im Artikel über den NetBird-Server.

Und diesmal hat die Warnung recht.

Was ich mitnehme

Ein Server muss nicht erreichbar sein, um ein echtes Zertifikat zu bekommen. Es reicht, dass er die Einträge seiner Domain ändern darf. Ein Wildcard, ein Eintrag im internen Telefonbuch und ein Pförtner davor machen aus jedem neuen Dienst einen einzigen Eintrag im Proxy, ohne DNS-Änderung und ohne neues Zertifikat. Dass die Zertifikatsnamen öffentlich im Logbuch stehen, spricht zusätzlich für das Sternchen.

Das Wichtigste ist aber die Gewohnheit vom Anfang. Bei mir zu Hause gibt es keinen Grund mehr für eine Zertifikatswarnung. Wenn doch eine auftaucht, klicke ich nicht weiter, ich halte an und schaue nach, wo ich gelandet bin.

Wie der restliche Weg aussieht, vom Handy unterwegs durch den Tunnel bis zum Dienst, und warum sogar im eigenen LAN fast alles verschlüsselt läuft, erzählt Teil 2: Netz & Zugriff.