Letsencrypt Zertifikat ohne Serverzugriff von "außen"


#1

Hallo zusammen,

da ich einige Probleme mit selbstsignierten Zertifikaten in Zusammenhang mit LineageOS 14.1 habe, wollte ich mal schauen ob ich es nicht eventuell doch mit Letsencrypt lösen kann.

Also mein Ziel ist per https im LAN mit meinem Seafile Server zu kommunizieren, der Server soll nicht von außen erreichbar sein.
Nun zu meiner Frage, ist es möglich ein Letsencrypt Zertifkat zu bekommen und auch zu erneuern ohne, dass mein Server von außen zugreifbar ist?


#2

Ich hätte das auch gerne. Aber ich tippe auf “nein”. Bei Letsencrypt besteht die einzige Überprüfung, ob man ein Zertifikat bekommt darin, automatisch zu prüfen, ob Du die Website, zu der Du ein zertifikat haben willst, ändern kannst. Dazu fordert der Letsencrypt-Server Dich auf, eine bestimmte Datei (mit einer zufälligen Zahlenkette) kurz auf dem Server verfügbar zu machen. Der Letsencryserver ruft die Website ab und testet, ob Du das gemacht hast. Wenn ja, stellt Letsencrypt Dir ein Zertifikat aus.
Wenn Dein Server allerdings für den Letsencrypt-Server nicht erreichbar ist (weil er nur um LAN erreichbar ist), dann kann er nicht prüfen, ob Du Zugriff auf die Website hast.

Da fällt mir ein, wie man das Problem vielleicht lösen könnte:

  1. Du erstellst Dir eine öffentliche Domain, z.B. seafile.abcencrypt.de
  2. Du richtest auf dieser Domain einen im Internet erreichbaren Webserver ein.
  3. Du richtest letsencrypt für diese Seite ein.
  4. Du kopierst regelmäßig von dem öffentlichen Server das Letsencrypt-Zertifikat auf Deinen privaten Server, der nur im LAN erreichbar ist
  5. Auf Deinem Client-Rechner ergänzt Du in die Datei HOSTS (%SystemRoot%\system32\drivers\etc\hosts) für seafile.abcencrypt.de die IP-Adresse Deines lokalen seafile-servers ein.

Das müsste funktionieren.

Viele Grüße,
Pfeffer.


#3

Darf der Server nicht von außen erreichbar sein, oder kann er nicht?

Viele Grüße
Markus


#4

Er soll nicht erreichbar sein, ich würde mir einfach gerne die Möglichkeit offen lassen ihn nicht von außen erreichbar zu machen.
Dein Vorschlag klingt sehr interessant Pfeffer, das werde ich mir mal näher ansehen.
Ist das eigentlich auch mit Android als client möglich, insbesondere wenn sie nicht gerootet sind?


#5

Es würde ja auch reichen den Server temporär zugänglich zu machen, bei Erstellung und beim renew des Zertifikats alle 90 Tage (so lange gilt das Zertifikat meine ich). Eventuell lässt sich das sogar durch ein script erledigen.


#6

Wäre mir gerade nicht bekannt, dass man die Hosts-Datei bei Android anpassen kann. Bin mir da aber auch nicht zu 100% sicher.
Ich persönlich würde einen Webserver ala nginx oder Apache auf Port 80 laufen lassen, welcher ins “Leere” geht. Darüber kann der Certbot von letsencrypt sein Zertifikat validieren und gut ist. Seafile kann dann ja weiterhin über 443 nicht von extern erreichbar sein. Letztendlich könnte man das wie von nihilistaX schon gesagt auch einfach scripten, dass Port 80 nur während der Ausfürungszeit der Certbots offen ist.

Die Frage ist, warum es überhaupt https sein muss, wenn es doch nur lokal läuft? :wink:

Viele Grüße
Markus


#7

Bei Android kann die Hosts-Datei nur mit einem gerooteten Gerät bearbeitet werden. Das geht dann z.B. mit der App adaway. Ich würde mich aber auch der Frage anschließen, wofür du dir den ganzen Aufwand machst.


#8

Für diesen Fall sieht Let’s Encrypt eine DNS-Challenge vor. Lies: Du benötigst einen DNS-Server, den Du per Script konfigurieren kannst.

Ich habe soetwas laufen und nutze dafür dehydrated mit einem passenden Hook, siehe: (https://github.com/lukas2511/dehydrated/blob/master/docs/dns-verification.md) Funktioniert bei mir problemfrei.


#9

Danke zunächst einmal für die ganzen Antworten.
Also wozu ich den ganzen Spaß (auch) nur fürs LAN machen ist folgendes:

  1. Ich möchte das ganze mal auch bei Freunden/Bekannten einrichten und da habe ich dann einfach Bauchschmerzen wenn das ganze “nur” über http läuft. Wer weiß schon wem dort alles Zugriff zum Heimnetz gewährt wird, ich weiß, dass https kein Allheilmittel ist, aber es ist zumindestens eine weitere Hürde die man zunächst nehmen muss und man dann eben nicht durch einfaches Netzwerk belauschen sämtliche Passwörter abgreifen kann.
  2. Möchte ich mir die Möglichkeit offen halten den Server eben doch von außen zugänglich zu machen und da ist es dann praktisch wenn schon eine gewisse Vorarbeit erledigt ist, insbesondere bei Installationen für Freunde/Bekannte.

@germeier
Die Lösung mit DNS klingt auch interessant, aber mir ist noch nicht klar wie das konkret läuft, braucht man dann auch wieder eine offizielle Domain und muss dann intern die offiziele Domain auf die interen IP umbiegen, oder wie läuft das?

@pfeffer
Kann ich nicht eigentlich auch in meiner Fritzbox die Domain auf die interne IP umbiegen, oder behelfsweise auf einem externen DNS-Server, welchen man ja z.B. auf der gleichen Hardware wie den Seafile Server installieren könnte.

Die Idee mit dem temporären Öffnen der Ports hatte ich auch schon, aber dazu müsste ich ja per Skript auf den Router zugeifen können oder wie meint ihr das?
Zudem wird das dann wohl auch aufwendiger sobald man einige Installationen betreut.


#10

Genau, Du benötigst eine offizielle Domain. Let’s Encrypt stellt Dir nur ein Zertifikat aus, wenn Du beweisen kannst, dass Du Kontrolle über die Domain hast. In der Regel geht das über einen Webserver. Du kannst das aber auch mit einem DNS-Server machen, was halt etwas “anstrengender” ist.

Der DNS-Server Deiner Domain muß nicht zwingend Deine lokalen IP-Adresse auflösen können, kann das aber sehr wohl tun. Wenn Du eine große Firma bist, dann willst Du nicht, dass Deine lokalen IP-Adressen nach aussen sichtbar sind. Daher: Über den globalen DNS-Server machst Du Let’s Encrypt und über einen DNS-Server in Deinem Heimnetz löst Du Deine lokalen Namen auf. Da würde ich jetzt nicht von “umbiegen” reden. Deine Clients fragen Deinen lokalen DNS-Server und da der das besser weiß, ist der bei lokalen Namen nicht genötigt eine externe Anfrge zu stellen.

Bei meinem lokalen Heimnetz mit einer flachen Hierarchie ist das Leaken von IP-Adressen nicht etwas wovor ich Angst habe. Daher trage ich einfach meine lokalen IP-Adressen in den globalen DNS-Server ein. Jetzt kann man herausfinden, welche IP-Adressen meine Geräte daheim haben, da ich aber auch im internen Netz alles nur verschlüsselt über die Leitungs schicke, ist das nicht ein Angriffsszenario vor dem ich am meisten Angst habe.

HTH!


#11

OK danke vielmals für die ausführlichen Erklärungen, ich werde mich die Tage mal ein bisschen einlesen und es dann mal probieren.


#12

Weil ich das gerade lese: mit Fritzbox sollte es so gehen:

  • auf “myfritz.net” einen DNS Eintrag machen (DDNS, dyndns)
  • Port 80 der Box auf den Linuxrechner weiterleiten
  • dort einen webserver horchen lassen und
  • dehydrated installieren, konfigurieren, starten

Dann hat man ein Zertifikat. Das kann ein Webserver an beliebigem Port dann verwenden und Clients, in LAN wie WAN, können auch ohne Einträge in ihrer hosts-Datei dahin verbinden, sobald und solange die Box auch diesen Port weiterleitet.

PS: dehydrated sollte aus dem cron laufen, einmal am Tag, mindestens einmal die Woche. Die Portweiterleitungen müssen dauernd bestehen. Mit andren Routern geht das meist gleich.


#13

Moin!

Ich habe es für mich etwas anders gelöst:

In meiner FritzBox sind die Ports standardmäßig auch geblockt. Allerdings habe ich UPnP aktiviert und nutze unter Linux das Kommandozeilentool upnpc um die Ports bei einem benötigten Renewal Prozess automtaisch zu öffnen und anschließend wieder zu schließen. Das Ganze sieht dann so aus:

certbot renew --pre-hook “service nginx stop && upnpc -a 192.168.178.4 443 443 TCP && upnpc -a 192.168.178.4 80 80 TCP” --post-hook “service nginx start && upnpc -d 443 TCP && upnpc -d 80 TCP”

Wobei in diesem Fall 192.168.178.4 die interne IP des Servers ist.

Funktioniert für mich gut und war so am wenigsten aufwändig.

Nur beim ersten einrichten der Zertifikate habe ich die Ports manuell geöffnet.

Beste Grüße
themmm


#14

Hallo zusammen,
letsencrypt ist nur sinnvoll für einen server, der über das Internet erreichbar ist und auf den man auch über eine öffentliche URL zugreifen will. Selbst wenn man ein Letsecnrypt Zertifikat für z.B. beispiel.domain.de für seafile nutzt, wird man immer einen Sicherheitshinweis bekommen, wenn man über eine lokale IP oder eine andere URL darauf zugreift.

Dabei ist es unter Linux doch total einfach sich selbst ein Zertifikat zu erstellen und SEafile per HTTPS zu betreiben.
In diesem Video wird beschrieben, wie es geht:

Gruß
Christoph


#15

Falsch! Es hat doch einen Grund warum ACME eine DNS-Verifikation vorsieht!

Ausserdem: Was ist eine öffentliche URL? URLs kennen das Konzept von öffentlich und privat nicht.

Warum will ich über eine IP Adresse oder eine andere URL auf den Server zugreifen, wenn ich gerade ein Let’s Encrypt Zertifikat erstellt habe?

Grundsätzlich ist es ganz schlechter Stil Dienste über IP-Adressen anzubieten. DIe haben nämlich die Eigenschaft, dass die sich ändern können und das man sich die nicht merken kann.

Ja, es ist unter Linux total einfach ein Zertifikat über Let’s Encrypt zu erzeugen!