LetsEncrypt Certbot-Fehler wenn Pi-Hole als DNS

Scheint nichts zu werden im LetsEncypt-Forum...
Läge am falsch konfigurierten DNS-Server...
Ja, mag sein, nur was wo checken? Was macht Pi-Hole anders, als die FB? Wie kann man Pi-Hole möglichst transparent machen? Welche Logs sind hilfreich?

Möglicherweise unterbindet eine Firewall oder Docker selbst den Zugriff auf Pi-holes IP-Adresse.
Das hätte aber bei den nslookups sofort auffallen müssen - es sei denn, Du hast die Kommandos nicht auf der Maschine ausgeführt, die Deine Zertifkate erneuert, sprich: aus dem entsprechenden Container heraus.

Hast Du die nslookups aus einer Shell im certbot-Container abgesetzt?

Von der Shell auf dem Pi.
Das Problem ist, dass der docker sofort wieder stirbt und ich keine Möglichkeit gefunden habe, ein docker exec in den Container zu machen...

docker run -it --rm -v /home/hajo/docker/letsencrypt/etc/letsencrypt:/etc/letsencrypt -v /home/hajo/docker/letsencrypt/var/lib/letsencrypt:/var/lib/letsencrypt -v /home/hajo/docker/letsencrypt-docker-nginx/src/letsencrypt/letsencrypt-site:/data/letsencrypt -v "/home/hajo/docker/letsencrypt/var/log/letsencrypt:/var/log/letsencrypt" certbot/certbot:arm64v8-latest certonly --webroot --register-unsafely-without-email --agree-tos --webroot-path=/data/letsencrypt --staging -d <myDomain>`

Ich vermute aber inzwischen, dass das der richtige Pfad ist.
Wenn ich einen anderen Container starte, ist dort zwar weder ping noch nslookup installiert, wenn ich dort aber ein apt-get update mache, sehe ich Temporary failure resolving 'deb.debian.org.

Stellt sich also die Frage, warum das geht wenn Pi-Hole nicht da ist?
Mag es an den Ports liegen? Pi-Hole nutzt ja wohl 53, 80 und 443. Deshalb muss man z.B. einen nginx-Container nach außen z.B. auf 9080 schauen lassen und auf intern 80 mappen.

Auch ohne Docker Expertin zu sein, versuch:

docker run -it --rm -v /home/hajo/docker/letsencrypt/etc/letsencrypt:/etc/letsencrypt -v /home/hajo/docker/letsencrypt/var/lib/letsencrypt:/var/lib/letsencrypt -v /home/hajo/docker/letsencrypt-docker-nginx/src/letsencrypt/letsencrypt-site:/data/letsencrypt -v "/home/hajo/docker/letsencrypt/var/log/letsencrypt:/var/log/letsencrypt" certbot/certbot:arm64v8-latest bash

Das bash am Ende sollte Dich auf eine Terminal bringen. Falls das nicht funktioniert, vielleicht mit sh probieren. In diesem Container solltest Du den Prozess dann mit dem restlichen Befehl jederzeit starten können:

certbot certonly --webroot --register-unsafely-without-email --agree-tos --webroot-path=/data/letsencrypt --staging -d <myDomain>`

edit:

Nur 53 und 80. Und 80 ist optional, nur für die Webserver. Alles funktioniert auch wenn nur 53 durchgeleitet wird.

Leider nicht: certbot: error: unrecognized arguments: sh

Wie werde ich den am schnellsten zum Test mal los?
Und falls es das ist, wie am besten dauerhaft auf einen anderen Port gebogen?

Im docker-compose.yaml habe ich nur Port 53 stehen:

 - "53:53/tcp"
 - "53:53/udp"

Vielleicht /bin/bash

Dafür sorgt --rm.

Theoretisch müsstest Du eine Shell für ein Image <image-name> über folgendes Kommando erreichen können:

docker run -it --rm <image-name> bash

Ob das funktioniert, hängt aber auch davon ab, wie das Image gebaut wurde und auf welche Parameter es angewiesen ist.
Das lässt sich nur vorab nur über die Dokumenation für das certbot-Image herausfinden, oder einfach durch Ausprobieren.

Stirbt auch ohne --rm.
Und leider geht weder /bin/sh, noch docker run -it --rm certbot/certbot:arm64v8-latest bash

Letzter Versuch:

docker run -it --rm --entrypoint sh certbot/certbot:arm64v8-latest
2 Likes

Sehr gut!!!

Bestätigt voll und ganz den Verdacht.

$ nslookup acme-staging-v02.api.letsencrypt.org
;; connection timed out; no servers could be reached


$ nslookup acme-staging-v02.api.letsencrypt.org 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8:53

Non-authoritative answer:
acme-staging-v02.api.letsencrypt.org	canonical name = staging.api.letsencrypt.org
staging.api.letsencrypt.org	canonical name = 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com
Name:	56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com
Address: 172.65.46.172

Non-authoritative answer:
acme-staging-v02.api.letsencrypt.org	canonical name = staging.api.letsencrypt.org
staging.api.letsencrypt.org	canonical name = 56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com
Name:	56a5f4b0bc8146689ec3e272c43525f9.pacloudflare.com
Address: 2606:4700:60:0:f41b:d4fe:4325:6026

Wenn ich statt 8.8.8.8 meine FB (192.168.178.1) angebe, geht's auch.

Und nun die Frage, warum der Pi-hole verhindert, dass der Container den nslookup hinbekommt; ohne scheint er das ja zu schaffen, da der certbot erfolgreich raus kommt.
Evtl. wg. Port 80 für das Web-Interface?

Du wirst vermutlich für den nslookup keine Einträge im Query Log sehen, weil die DNS-Anfragen Pi-hole nie erreichen.

Also wird das wird nicht an Pi-hole liegen, sondern entweder an Docker oder an Ubuntus Firewall-Einstellungen.

Es wäre wahrscheinlich einfacher, direkt mit Certbot (statt mit Certbot in Docker) zu arbeiten.

Das empfiehlt auch Certbots eigene Anleitung zu Running with Docker für die meisten Anwender.

Ja, das sehe ich auch so.

Denke eher an der docker-Konfiguration oder dem verwendeten Netzwerkmodus. Wenn Firewall, würde ich erwarten, dass die immer blockt, egal ob Pihole da ist, oder nicht.

Ja. Aber...
Die Gründe verstehe ich auch eher in dem Bereich der automatischen Webserver-Konfiguration.
Ich würde es halt lieber gekapselt betreiben und hoffe trotz der gegenteiligen Empfehlung auf weitere gute Ideen!
Nochmal Dank Euch beiden für Geduld und das gute Eingrenzen der Ursache.

Interessant wäre noch, über welche Adresse der Certbot-Container die Auflösung versucht.

Was gibt cat /etc/resolv.conf aus Certbot jeweils zurück, wenn Pi-hole oder die FB als lokaler DNS-Server verwendet werden?

$cat /etc/resolv.conf

nameserver 192.168.178.3
search fritz.box

Also die IP meines PI (mit Pi-Hole).
Entspricht dem auf dem PI selbst, so dass ich davon ausgehe, dass es bei Umkonfiguration auf FB in beiden Fällen mit 192.168.178.1 antworten würde.

Du könntest versuchen, in Deinem Certbot-Container mit der IP-Adresse der FB als DNS zu arbeiten, indem Du --dns=192.168.178.1 zu Deinem docker run hinzufügst.

Wenn das funktioniert, könnte man sich die Suche nach der korrekten Ubuntu/Docker-Netzwerkintegration mit Pi-hole sparen.

1 Like

Yep :clapping: :clapping: :clapping:
Das ist zwar nicht die Lösung, aber sicher ein guter Workaround!!!
Der komplette Befehl (für den Probelauf) lautet dann also:


docker run -it --dns=192.168.178.1 -v /home/hajo/docker/letsencrypt/etc/letsencrypt:/etc/letsencrypt -v /home/hajo/docker/letsencrypt/var/lib/letsencrypt:/var/lib/letsencrypt -v /home/hajo/docker/letsencrypt-docker-nginx/src/letsencrypt/letsencrypt-site:/data/letsencrypt -v "/home/hajo/docker/letsencrypt/var/log/letsencrypt:/var/log/letsencrypt" certbot/certbot:arm64v8-latest certonly --webroot --register-unsafely-without-email --agree-tos --webroot-path=/data/letsencrypt --staging  -d <myDomain>

Auf diese Weise nutzt der certbot-Container nicht den Pi-hole, sondern die Fritzbox als DNS-Server (oder eben einen anderen gewählten Server) und kann dann auch die Namen auflösen. Warum die Namensauflösung mit Pi-Hole als DNS-Server nicht geht, ist noch nicht verstanden!


Wenn es für Dich/Euch okay ist, würde ich diesen Post - auch wenn es von Euch beiden erarbeitet wurde - als Lösung markieren, falls nochmal jemand Certbot und Pi-Hole in docker laufen lassen möchte.

Über die Lösung entscheidet normalerweise der Gelöste selbst. :wink:

Das kann auch gerne Dein obiger Beitrag sein, der ja auch schon das entsprechend präparierte Kommando enthält.

Können sie gerne tun, aber bitte noch eine Kurzzusammenfassung zum Befehl als Lösung dazuschreiben. Damit sich User mit die gleiche Probleme nicht durch 35 Posts arbeiten müssen.

Bin deswegen in 'nem anderen Forum schon mal angemacht worden; ich würde mich mit fremden Federn schmücken...

s.o.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.