@Dennis_Admin
Kann mir bitte jemand helfen? Ich möchte gerne meine Services in meinem Homelab mit Let‘s Encrypt Zertifikaten ausstatten und trotzdem keine Ports öffnen. Ich habe dann ein bisschen recherchiert und dann eine Lösung gefunden: Man braucht ja für Let‘s Encrypt eine öffentliche Domain, also wollte ich mir eine Domain bei ipv64.net holen und diese dann für das SSL-Zertifikat nutzen und die Domain auch in meinem Pi-Hole hinzuzufügen. Damit sollte es ja eigentlich klappen, dass ich vertrauenswürdige Zertifikate in meinem lokalen Homelab haben. Aber ich scheitere gerade bei der DNS-Challenge für das SSL-Zertifikat bei meinem Reverse Proxy Traefik. Ich weiß nicht welche URL die API ist und so… Ich hoffe einer von euch konnte mir bis hier hin folgen 
und ich würde mich sehr über eure Hilfe freuen! Ich denke, dass wird einige hier interessieren und ich glaube ein YouTube Video darüber würde sehr gut ankommen 
LG
Hi,
ohne offene Ports wird das eher nichts. Port 80 und 443 müsste in jedem Fall nach außen geöffnet sein da Letsencrypt darüber kommuniziert und die Zertifikate am Server abspeichert. Die einzige alternative dazu wäre auf einem Public Webspace irgendwo ein Zertifikat erstellen lassen und dieses dann manuell kopieren und intern nutzen. Den Spaß machst du dann allerdings alle 3(?) Monate da die Zertifikate nur 3(?) Monate gültig sind.
Ja das dachte ich auch bis ich dieses Video gefunden habe…
Letsencrypt braucht nur Port 80
Nö, man kann auch nur für den Zeitraum der Erstellung/Erneuerung des/der Zertifikate Port 80 öffnen. Mach ich seit Jahren so, denn meine Nextcloud ist nur via 443 erreichbar, darüber können die Zertifikate aber NICHT erneuert werden. Das geht nur über 80. Also alle 90 Tage Port 80 auf, Zertifikate erneuern, Port 80 wieder dicht.
Jup kann man natürlich so machen aber dennoch sind da kurzzeitig Ports offen. Auch wenn es ggf. nur Minuten sind. Der Ersteller will aber keine Ports öffnen.
Anyway im Grunde sagen wir dasselbe 
@sugarle Hast recht und unrecht. Wenn ein Server eh nicht auf Port 80 hört, wie meine Nextcloud läuft jede Anfrage ohnehin ins Leere. Zudem mach ich das nur via IPv6. Es gibt schlicht keinen A-Record für die Nextcloud. Letsencrypt bevorzugt ohnehin IPv6 wenn ein AAAA-Record vorhanden ist. Daher kann auf NAT und v4 komplett verzichtet werden.
Das Video sagt aber doch eigentlich alles, woran hängt es denn genau?
Wie sieht deine Traefik config aus usw.?
EDIT: eigentlich ist hier alles sehr gut Dokumentiert, IPv64 existiert sogar als Provider, du brauchst also nur den API key etc.
Ich komme bei der Traefik config noch nicht so gut zurecht aber ich habe schon ein Video gefunden um das zu machen danke für eure Zeit
Traefik ist auch eher etwas für Cluster find ich. Also sei es Kubernetes, Swarm usw.
Also eher wenns um automatische Sachen geht. Traefik kann zwar auch alles was jeder andere Proxy kann aber eben nur mit umständlichen configs.
Ja stimmt ich werde dann wohl auf den NGINX Proxy Manager zurückgreifen aber selbst da bekomme ich das mit der DNS Challenge nicht hin…
Ich würd eher zu Zoraxy greifen aber grundlegend dasselbe vorgehen, du wählst die DNS Challenge und entweder hinterlegst du den DNS TXT Record manuell oder lässt ihn via API setzen.
Du müsstest schon mit mehr Infos kommen woran es genau scheitert.
Hi,
durch Zufall hab ich die Woche den Wechsel von Zoraxy auf Traefik gemacht. Beim Zoraxy hatte ich das Problem, dass das Admin Panel selbst größe Ladeprobleme von Extern hatte. Ansonsten finde ich Zoraxy auch ein guten und einfachen Revers Proxy. Gut, darum geht es aber in dem Thema nicht 
Zurück zum Traefik, wie habe ich jetzt die DNS Challenge umgesetzt.
Ich habe CDN mit Reverse Proxy auf Level zwei (Frontend und Backend) aktiv. Dadurch wird der eingehende Verkehr grundsätzlich auf https : 443 umgeleitet. Bei mir ist auch nur der 443 nach außen offen.
Im „docker-compose.yml“ des Traefik ist dann folgende Variable gesetzt:
environment:
IPV64_API_KEY: 'Dein Account Update Token im IPv64.net - Account Status'
In der „/etc/traefik/traefik.yml“ sind dann folgende Variablen bezüglich SSL enthalten:
entryPoints:
web:
address: ":80"
websecure:
address: ":443"
http:
tls:
certResolver: ipv64
providers:
docker:
exposedByDefault: false
certificatesResolvers:
ipv64:
acme:
email: deine@mail-adresse.de
storage: /letsencrypt/acme-ipv64.json
dnsChallenge:
provider: ipv64
delayBeforeCheck: 30s
Die traefik.yml und acme-ipv64.json werden dabei im Volume über das Docker-Compose gemountet.
Theoretisch brauchst du web (Port: 80) wahrscheinlich nicht. Der ist bei mir noch drin, da ich wie geschrieben, die Woche erst alles umgestellt habe. Sprich ich bin jetzt noch in den Feintuning.
Warum hab ich da bei mir jetzt so umgesetzt? So entscheide ich welcher Container von außen erreichbar ist und durch das CDN bzw. den Reverse Proxy von ipv64, ist dieser dann nur per 443 erreichbar. Weiter durch die DNS-Challenge zieht sich der Traefik dann automatisch das SSL Zertifikat über ipv64.
Sprich der Weg ist bis zum Container verschlüsselt mit SSL Zertifikat versehen (zumindest laut Dashboard 
).
Ok, was sind jetzt die wichtigen Variablen im docker-compose des jeweiligen Containers (Applikation):
labels:
# Aktiviert Traefik für den Container
traefik.enable: "true"
# Definiert deine (Sub-)Domain
traefik.http.routers.app.rule: Host(`app.deine.domain.de`)
# definiert den Zugangspunkt inkl. SSL Zertfikat
traefik.http.routers.app.entrypoints: websecure
# Leitet auf den internen Container-Port um (nicht der Docker Port)
traefik.http.services.app.loadbalancer.server.port: "80"
Bitte „app“ durch den Namen der jeweiligen Applikation ändern.
Das sind nur die Rahmenparameter zu TLS/SSL. Natürlich gibt da noch paar andere Dinge, aber das würde glaube den Rahmen sprengen und den Spaß am selber ausprobieren nehmen
Ich sage nur: Unifi Admin Panel, das Thema File als Provider, Portainer, Authelia, usw.
Was habe ich in der Woche der Umsetzung gelernt: Traefik bietet meistens mehr als einen Weg, Themen zu lösen. An der Stelle, wie geschrieben, so habe ich aktuell das Thema TLS/SSL gelöst, es gibt aber bestimmt noch genug andere
Ich hoffe das hilft dir weiter.
Ein letzter Tipp noch, du solltest während Umsetzungsphase dein Log auf Debug umstellen, um zu sehen was in der DNS-Challenge passiert.
Die Einstellung hab ich auch in der „traefik.yml“ und einsehen tu ich den Log faul über den Portainer.
Config in der „traefik.yml“:
log:
level: "debug"
Viel Erfolg
Wow was für eine benutzerdefinierte Dokumentation! Vielen Danke dafür! Das ist genau das was ich haben wollte. Kurze Frage: Warst du auf einem Gymnasium? Deine Texte mit Fazit usw. sind ja schon sehr streber mäßig Vielen Dank jeden Falls!!!
Danke für das Kompliment 
Hab in einer klassischen IT-Abteilung gelernt und bin seid über 10 Jahren im IT-Vertrieb im Innendienst.
Bin halt auch Faul, Dokumentieren liebe etwas mehr und versuch Verständnis bei den Kollegen und Kunden zu wecken, so dass Sie es nachvollziehen können. Lerneffekt und Erfolge, statt 5mal Nachzufragen
Und ich mag kein Mail Ping-Pong
Letztendlich sind wir hier eine Community und nur als Team ist man Stark.
Moin!
ich brauche zu dem Thema in Kombination mit treafik hilfe.
Ich bekomme kein LE-Zertifikat. Ich sehe in den Logs und im IPv64 Backend, dass er für die Domains die txt Einträge anlägt, aber ich bekomme dann ein propagation timeout. Habe die Timeouts selber aber schon sehr hoch gestellt:
- IPV64_HTTP_TIMEOUT=600
- IPV64_POLLING_INTERVAL=10
- IPV64_PROPAGATION_TIMEOUT=600
bringt aber auch keine besserung ausser, dass das länger dauert.
Genaue Fehlermeldung ist:
[INFO] [xxx] acme: Waiting for DNS record propagation. lib=lego
[...]
[INFO] [xxx] acme: Cleaning DNS-01 challenge lib=lego
[WARN] [xxx] acme: cleaning up failed: ipv64: error (403 Forbidden): del_record lib=lego
2025-04-30T17:18:45+02:00 DBG github.com/go-acme/lego/v4@v4.23.1/log/logger.go:48 >
Unable to obtain ACME certificate for domains error="unable to generate a certificate for the domains [xxx]: error: one or more domains had a problem:\n[xxx] propagation: time limit exceeded: last error: authoritative nameservers: NS ns2.ipv64.net.:53 returned NXDOMAIN for _acme-challenge.xxx.\n" ACME CA=https://acme-staging-v02.api.letsencrypt.org/directory acmeCA=https://acme-staging-v02.api.letsencrypt.org/directory domains=["xxx"] providerName=ipv64.acme routerName=https-xxx@docker rule=Host(`xxx`)
die traefik.yaml sieht so aus
[...]
entryPoints:
http:
address: ":80"
http:
redirections:
entryPoint:
to: "https"
scheme: "https"
priority: 1000
https:
address: ":443"
http:
tls:
certResolver: ipv64
certificatesResolvers:
ipv64:
acme:
email: "xxx"
storage: "/var/traefik/certs/acme-ipv64.json"
# caServer: https://acme-v02.api.letsencrypt.org/directory # prod (default)
caServer: https://acme-staging-v02.api.letsencrypt.org/directory # staging
dnsChallenge:
provider: ipv64
delayBeforeCheck: 30s
resolvers: ["159.69.110.93:53", "167.235.231.182:53"]
[...]
jemand eine Idee was das sein kann? Ich finde auch den access denied merkwürdig für das löschen des txt eintragen. Anlegen geht ja.
Ich hab das Problem gefunden, weiß nur noch nicht wie das lösen kann… ich versuche Zertifikate für dienst.home.lab.de anzulegen daher sollten TXT einträge im Format _acme-challenge.dienst.home.server.de angelegt werden, es wird aber nur _acme-challenge.dienst.lab.de angelegt.
Gelöst das Problem saß vor dem PC
Aber falls auch jemand drauf stößt und sich fragt warum.
Die Subdomain als eigene Domain anlegen. Damit geht das dann. Also nicht nur „lab.de“ sondern auch „home.lab.de“ im Backend anlegen