Ich habe Pi-Hole als docker-container auf meinem Raspberry Pi unter ubuntu 20.04 laufen.
Ich möchte nun über LetsEncrypt ein Zertifikat generieren/holen.
Das funktioniert sehr schön, wenn ich auf meiner Fritzbox nicht Pi-Hole als DNS-Server eintrage.
Wenn ich dort aber den Pi als DNS-Server angebe, erhalte ich diese Fehlermeldung:
An unexpected error occurred:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='acme-staging-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff899f6400>: Failed to establish a new connection: [Errno -3] Try again'))
Ich sehe keinen geblockten Eintrag im Pi-Hole.
Das Verhalten ist das gleiche, wenn ich Pi-Hole disable.
Warum kommt LetsEncrypt nicht klar, wenn der Pi-Hole als DNS-Server fungiert?
Es geht mir hier (noch) nicht darum, Pi-Hole über https anzusprechen...
Da das Pi-Hole Web-Interface Port 80 belegt, habe ich einen nginx-container auf Port 9080 laufen. Um das Zertifikat zu holen, öffne ich Port 80 auf der Fritzbox und leite diese Freigabe auf Port 9080 weiter. Wie gesagt: Ohne Pihole als DNS klappt das alles einwandfrei...
Welche DNS-Server benutzen Sie? Wenn Sie das Pi-hole umgehen, dann nutzt die Fritzbox wahrscheinlich nicht die gleichen, die sie im Pi-hole eingestellt haben. Die gleichen Server werden auch benutzt wenn Pi-hole disabled ist. Vielleicht ist der Problemquelle?
Ich habe auf der Fritzbox den Pihole-Pi bei lokalen DNS-Server (wie hier beschrieben) eingetragen.
Unter Internet / Zugangsdaten / DNS-Server habe ich (wie hier beschrieben) die Einstellung Vom Internetanbieter (1&1) zugewiesene DNSv4-Server verwenden nicht geändert. Welcher das ist, weiß ich nicht.
Das Problem lässt sich jedoch nicht durch enable/disable des Pihole beheben.
Bisher einizige Lösung ist bei der lokalen DNS-Server-Einstellung bei der Fritzbox-IP (192.168.178.1) zu bleiben.
Kann Pi-hole sowohl die angeforderte letsencrypt-Domäne als auch Deine eigene Domäne auflösen?
Ausgeführt auf der Maschine, die die Zertifikatserneuerung durchführen soll, was geben folgende Kommandos zurück:
nslookup acme-staging-v02.api.letsencrypt.org
nslookup <deine.domain.de>
Natürlich ist dabei <deine.domain.de> durch den korrekten Namen zu ersetzen.
Sieht fast so aus, ist aufgrund der Verschleierung Deiner IP-Adressen aber nur durch Dich zweifelsfrei zu beurteilen.
Wenn es keinen Unterschied gibt, kann Pi-hole auch nicht beteiligt sein, zumindest soweit es die geprüften Domänen angeht.
Möglicherweise sind andere Domänen involviert, die von Pi-hole blockiert werden.
Du solltest diesbezüglich das Query Log während einer Zertifikatserneuerung auf geblockte Domänen untersuchen, z.B. über Tools | Tail pihole.log in Pi-holes Weboberfläche oder mit pihole -t auf der Kommandozeile.
Naja, das ist ja genau das, was ich nicht verstehe.
Ich sehe keinen geblockten Eintrag im Pi-Hole-Log.
Wenn ich Pi-Hole disable, geht es auch nicht.
Ich kann ja sogar den Container stoppen. - Wobei ich verstehen könnte, wenn es dann andere Probleme gäbe, da ja kein DNS-Server mehr im Netz zur Verfügung steht.
Oder anders herum: Ich trage auf der Fritzbox bei lokaler DNS-Server wieder die Fritzbox selbst ein.
Anschließend boote ich meinen Pi (weil ich nicht weiß, wie ich sicher den DNS-Server zurück setze), starte den Pi-hole-Container, der dann ja nichts macht, weil ihn keine anfunkt und schon klappt es.
Warum kommt LetsEncrypt - genauer Certbot - nicht klar, sobald der Pi-Hole als DNS-Server fungiert, egal ob er enabled oder disabled ist.
Wenn es tatsächlich keine geblockten Domänen liegt, kann DNS höchstens noch durch eine abweichende Auflösung der erlaubten Domänen zu Deinem Problem beitragen.
Für die beiden bisher untersuchten Domänen haben wir keine solche Abweichungen festgestellt.
Um herauszufinden, ob die von Pi-hole verwendeten Upstream DNS Server hier beteiligt sind, könntest Du testweise einmal nur Deine FritzBox als einzigen Upstream für Pi-hole einstellen.
Ich halte es aber auch nicht für unwahrscheinlich, dass der von Dir verwendete Certbot zum Fehler beiträgt.
Unter Ubuntu kommen sich bisweilen die certbot-Installationen von dpkg und snapd in die Quere:
sudo find / -xdev -name certbot
Ein Konflikt wäre möglich, wenn da mehrere certbots auftauchen, z.B. /usr/bin/certbot und /snap/bin/certbot.
Das wäre dann aber eher eine Sache für's Let's Encrypt Forum.
Es ist vielleicht keine schlechte Idee, auch dort ein Topic aufzumachen.
Solltest Du in der FB wieder auf die FB zurückgeschwenkt sein, muss nach dem Wechsel natürlich noch das DHCP-Lease auf dem Client erneuert werden, damit die Änderung auch auf dem Client ankommt.
EDIT:
Ein einfaches nslookup reicht, um den für eine Anfrage verwendeten DNS-Server herauszufinden.
Dann gibt es keinen konkreten Hinweis darauf, ob und wie DNS hier in den Fehler bei der Zertifikatserneuerung verwickelt ist.
Der Fehler: Max retries exceeded (...) Caused by (...) Failed to establish a new connection: [Errno -3] Try again
könnte z.B. auch durch fehlende Zertifikate, Verwendung von IPv6 statt IPv4, stark abweichende Uhrzeiten, Zugriffslimits oder einen veralteten Client verursacht werden.
Möglicherweise enthält Deine certbot-Ausgabe weitere Hinweise.
Diese wären jedoch am ehesten durch jemanden auswertbar, der sich mit certbot und letsencrypt auskennt.
DNS haben wir -soweit aus Deinen Versuchen ersichtlich- als Ursache ausgeschlossen.
Über die verbleibenden Punkte, von denen ich wahllos einige beispielhaft genannt habe, kann ich nur spekulieren. (für Details klicken)
Es geht nicht um Zertifikate für Deine Domäne, sondern um die für die SSL-Verbindung zu acme-staging-v02.api.letsencrypt.org. Eventuell fehlt Dir einfach entsprechendes CA-Zertifikat..
Da Deine Domäne auch über eine IPv6-Adresse erreichbar ist, könnte der externe Zugriff auf Port 80 durch die Let's-Encrypt-Validierung auch über diese erfolgen.
Wenn das in der FB nicht sauber konfiguriert ist, würde eine über IPv6 eingehende Validierunganfrage ggf. auf der FB hängen bleiben.
Mit Zugriffslimits sind nicht nur die rate limits für die Erneuerung des Zertifikats gemeint. Der Fehler nennt hier konkret das Überschreiten eines wie auch immer definierten Maximums.
Die Details zu jedem der Punkte lassen sich hier am besten mit jemandem klären, der sich mit der Deutung der Let's-Encrypt-Meldungen auskennt; daher nochmals der Hinweis auf das oben verlinkte Forum für Let's-Encrypt.
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?
