Wie muss ich LibreWorkspace einrichten, dass nur die Zertifikatsabfrage von Letsencrypt nach aussen geht?
Wie darf ich das verstehen?
Lets Encrypt Zertifikate werden nur geholt, wenn Du eine öffentliche Domain ausgewählt hast.
Was nach “außen” möchtest Du denn verhindern?
Ich möchte, dass LibreWorkspace nur für die Letsencrypt Zertifikate mit dem Internet kommuniziert. Aber sichergehen, dass ein Externer nicht die geringste Chance hat, auf den LibreWorkspace zuzugreifen. Ich möchte also die Zertifikate nur für mein Familien Intranet nutzen. Im Idealfall dürfen aus dem Internet nur Letsencrypt Zertifikatsserver mit LibreWorkspace kommunizieren und nichts anderes.
Ich habe bereits die ganze Familie mit Wireguard ausgerüstet und möchte, sobald LibreWorkspace läuft mein Wireguard durch Wireguard von Pangolin ersetzen.
Libre Workspace braucht für Updates auch Internetzungang.
Und Lets Encrypt verteilt nur Zertifikate, sobald der Server öffentlich erreichbar ist. (gibt eine Ausnahme, ist dennoch etwas komplizierter, und eher unüblich.
Wenn Du “lokal” bei der Domainauswahl, auswählst, dann ist Libre Workspace sein eigenes Lets Encrypt. Das würde ich Dir dann empfehlen.
Nachdem alles Installiert wurde, müsstest Du die Internetverbindung vom Libre Workspace im Router auch kappen können, sollte eigentlich klappen, auch wenn mir noch kein solcher Fall bekannt ist.
Eigentlich geht es mir nur um die erreichbarkeit von aussen, also Verbindungen die von aussen initiiert werden. Normale Internet verbindungen also verbindungen die von zuhause aus ins Internet gehen, sollten kein Problem sein, sofern sie über mein Pi-hohle gehen.
Achso,
das ist über die ACME Challenge soweit nicht möglich, meines Wissens nach.
Es gibt auch eine TXT-Challenge, wo das über einen TXT-Eintrag im DNS geht, aber damit haben wir selber noch keine Erfahrung, sollte man aber im Webserver einstellen können.
Kann ich denn im Router sicherstellen, dass nur Lets Encrypt mit meinem Port 443 und 80 kommunizieren darf?
Oder kann ich irgendwie den Lets Encrypt Abruf in einen Docker Container packen der nur Lets Encrypt enthält, damit ich die Portweiterleitung in meinem Router auf den Docker Container machen kann und mein Webserver nicht aus dem Internet erreichbar ist?
Ich möchte die Verantwortung, einen aus dem Internet erreichbaren Webserver zu administrieren nicht tragen.
Das machst Du über Port-Freigaben:
Aber genau das machst Du damit, dann lieber erstmal lokal betreiben 
Dann habe ich aber kein Letsencrypt. Ich möchte keine Zertifikate manuell zu Browser oder System hinzufügen
Genau das ist der Knackpunkt. Keine externe Erreichbarkeit = Kein Lets Encrypt Zertifikat.*
Wie sollen die denn sonst überprüfen ob man selber wirklich die Instanz ist, die man ausgibt zu sein?
*)
Als Alternative bietet Lets Encrypt noch die DNS-01 über TXT-Einträge an, die unterstützt der Libre Workspace oder soweit ich das Überblicken kann nicht mal caddy im Hauptmodul, da müsste man dann manuell ran.
Daher die Frage ob man Lets Encrypt vielleicht in einem Konteiner betreiben kann.
Dann kann ich den Webserver, der nur intern erreichbar sein soll vom Zertifikat trennen.
So könnte ich die Angriffsfläche noch etwas minimieren.
Du betreibst Lets Encrypt nicht selber.
Das ist ein Server im Internet, der “sichere HTTPS Zertifikate verteilt”.
Das ist schon klar. Ich meinte eher das script, das auf meinem PC die Anfrage entgegennimmt.
Das wird sehr schnell kompliziert, abgesehen von den Fehlern, die man dabei machen kann.
Ich würde als Startpunkt Certbot nehmen, und dann Caddy so konfigurieren, dass er die Zertifikate von Certbot verwendet. Weil dann kannst Du meine ich relativ gut steuern, wann er diese ACME Challanges macht.
Ein möglicher Ansatz der KI meines Vertrauns ist dieser hier.
Angaben ohne Gewähr:
# 1. Erstelle die Verzeichnisstruktur
# Dieses Verzeichnis wird von beiden Containern gemeinsam genutzt.
# Hier speichert Certbot die Zertifikate, auf die Caddy dann zugreift.
# Ändere ~/docker/letsencrypt zu einem Pfad deiner Wahl.
mkdir -p ~/docker/letsencrypt/{data,www}
# 2. Führe den Certbot-Container aus, um das Zertifikat zu erhalten
# Dieser Befehl startet einen temporären Container, der die Zertifikate von Let's Encrypt abruft.
# Die Ports 80 und 443 müssen während der Ausführung dieses Befehls
# auf deinen Server (nicht den Docker-Container selbst) weitergeleitet sein.
# Der --webroot-authenticator verwendet ein temporäres Verzeichnis (www)
# zur Verifizierung der Domain.
# Ersetze <your_domain.com> durch deine tatsächliche Domain und <your_email@example.com> durch deine E-Mail-Adresse.
# Beachte: Die --staging-Option wird für Tests empfohlen, um die Rate Limits
# von Let's Encrypt nicht zu überschreiten. Entferne sie, um ein
# gültiges Zertifikat zu erhalten.
docker run --rm -it \
-v ~/docker/letsencrypt/data:/etc/letsencrypt \
-v ~/docker/letsencrypt/www:/var/www/certbot \
certbot/certbot certonly \
--webroot \
--webroot-path=/var/www/certbot \
--email <your_email@example.com> \
--agree-tos \
--no-eff-email \
-d <your_domain.com> \
--staging
# 3. Passe die Caddy-Konfiguration in LibreWorkspace an
# Jetzt musst du Caddy anweisen, die Zertifikate aus dem neu gemounteten Verzeichnis zu verwenden.
# Ersetze den automatischen Zertifikats-Request durch eine manuelle Angabe.
# Deine Caddyfile sollte in etwa so aussehen:
#
# <your_domain.com> {
# # Stoppe die automatische Zertifikats-Erneuerung von Caddy
# tls /etc/caddy/ssl_certs/live/<your_domain.com>/fullchain.pem /etc/caddy/ssl_certs/live/<your_domain.com>/privkey.pem
#
# # Führe hier die restliche Konfiguration für deinen Webserver auf
# # ...
#
# # Optional: Erlaube nur lokale Zugriffe
# # (Falls du das nicht bereits im Router tust)
# # remote_ip private
#
# # Optional: Redirect von HTTP zu HTTPS, um die Zertifikatskette nicht zu gefährden
# # redir https://{host}{uri}
# }
#
# Wichtiger Hinweis: Wenn Caddy das Zertifikat nicht automatisch findet,
# musst du den Pfad manuell anpassen.
# Überprüfe den genauen Pfad im Container mit 'docker exec <container_name> ls -l /etc/caddy/ssl_certs/live'
# 4. Erneuerung der Zertifikate
# Zertifikate sind nur 90 Tage gültig. Du musst sie manuell erneuern.
# Dazu musst du nur Schritt 2 wiederholen.
# Die Befehle für die Erneuerung lauten:
# docker run --rm -it \
# -v ~/docker/letsencrypt/data:/etc/letsencrypt \
# -v ~/docker/letsencrypt/www:/var/www/certbot \
# certbot/certbot renew \
# --webroot \
# --webroot-path=/var/www/certbot
#
# Wichtig: Vor der Ausführung dieses Befehls musst du die Ports 80 und 443
# wieder auf deinen Server weiterleiten. Danach kannst du die Weiterleitung wieder deaktivieren.
Wäre das nicht mit DNS Challenge möglich. Ich habe das mit dem nginx Proxy Manager hinbekommen zum Testen. Wollte mich nach meinem Urlaub in Caddy einlesen damit ich das da auch hinbekommen.
Ich stelle fest, dass auch Pangolin am Ende ein Portal im öffentlich erreichbaren teil des Internets zur Verfügung stellt. Bislang scheint es keinen self-host Dienst zu geben, der das vermeidet und einen Abgeschotteten Betrieb ermöglicht. Ich bin Familien-Admin ich will die Potentielle Angrifsfläche so stark verkleinern wie es nur geht. Ich bin kein ausgebildeter Admin.
Ich brauche keinen Zugriff aus dem Internet, warum also das risiko eingehen?
Wenn es nicht anders geht, versuche ich das mit dem zertbot selber umzusetzen.
Danke für den Hinweis.
es gibt ein caddy modul für dns-01 challenge.
damit sollte das funktionieren.
ich drück dir die daumen und hoffe das klappt.
Ich erlaube in meinen Reverse Proxys immer den Zugriff auf das ./welknown/acme-challange Verzeichnis der Domäne über http port 80.
Alle anderen werden redirected auf die https Verbindung.
Müsste ich mal raus suchen, ich habe Beispiele vom HA Proxy im pfSense und irgendwo müsste ich auch noch was für’n NGINX haben.
Wenn der Caddy das kann, müsste das auch mit acme.sh funktionieren. Caddy leitet weiter, ACME.sh beantrag das Zertifikat und schiebt es dem Caddy unter.
acme.sh kann aber auch DNS Challanges mit zig verschiedenen Shared Hosting Anbietern und Stand Alone also würde dann selber port 80 belegen und die Let’s Encrypt Anfrage beantworten.
Standalone ist nur unschön weil man dann immer einen offenen Port in der Firewall hat, der keinen permanenten Endpunkt hat.