Nginx Reverse Proxy: DNS-Challenge klappt nicht

"DNSSEC: Bogus" bedeutet meinen Erfahrungen nach, dass es ein Problem mit den DNSSEC-Signaturen gibt. Prüfe mal deine Domains mit einem Tool wie DNSViz (einfach bei Google nach suchen). Das Tool kann dir diverse DNS-Probleme anzeigen und prüft auch die DNSSEC-Signaturen.

Brauchst du unbedingt Wildcard-Zertifikate? Wenn eh schon all deine (Sub-)Domains am NGINX Reverse Proxy zusammenlaufen ist es ansonsten auch ein leichtes einfach einen universell nutzbaren location-Block für die HTTP-Challenge in die Server-Blöcke einzubauen. Meiner sieht zum Beispiel so aus (ohne Garantie, dass es evtl. nicht noch etwas schöner geht, funktioniert aber 1A):

 location /.well-known/acme-challenge {
    root /var/www/html/acme-challenge;

    location ~/.well-known/acme-challenge/(.*) {
        default_type text/plain;
    }
}

/var/www/html/acme-challenge wäre in diesem Beipsiel dann immer der webroot_path für deine certbot-renewal.conf

Wieso "*" und nicht Domainname? Du möchtest die Challenge ja per Domain und nicht per Subdomain.

Hallo zusammen,

ich habe ebenfalls ein paar Probleme mit der DNS-Challenge und dem NGINX Proxy Manager.

Folgende Ausgangssituation:

- Domain A wird bei Netcup gehostet.

- Subdomain bei Domain A zeigt auf IP Adresse der Fritzbox; diese wiederum geht auf die IP (mit Port Forwarding) des NGINX Proxy Manager - das funktioniert auch alles soweit und der Dienst ist über die Subdomain erreichbar

- API Key und Passwort bei Netcup sind erstellt

Nun schlägt leider die Erstellung eines Lets Encrypt Zertifikats über die DNS Challenge im Proxy Manager fehl. Die Logs spucken folgendes aus (Domain ist zensiert):

DNS problem: NXDOMAIN looking up TXT for _acme-challenge.sub.example.de - check that a DNS record exists for this domain

Ich habe nun händisch einen TXT Record angelegt der wie folgt lautet:

Host: sub

Type: TXT

Destination: _acme-challenge.sub.example.de

Leider erhalte ich dennoch die selbe Fehlermeldung. Habe ich hier einen Gedankenfehler? Bin leider noch nicht so fit Zertifikatsthema und Netcup API

Grüße

Musst du denn unbedingt die DNS-Challenge verwenden? Reicht nicht die HTTP-Challenge?

Zitat von DooDafiit

Ich habe nun händisch einen TXT Record angelegt der wie folgt lautet:

Host: sub

Type: TXT

Der Meldung nach ("looking up TXT for _acme-challenge.sub.example.de"), brauchst du aber eher einen TXT-Eintrag für die subdomain _acme-challenge.sub, oder?

vor allem muss in diesen TXT record die challenge.

Zitat von Virinum

Musst du denn unbedingt die DNS-Challenge verwenden? Reicht nicht die HTTP-Challenge?

Gute Frage. Weißt du, wie ich das in Netcup und im Proxy Manager einrichten muss?

Zitat von aRaphael

Der Meldung nach ("looking up TXT for _acme-challenge.sub.example.de"), brauchst du aber eher einen TXT-Eintrag für die subdomain _acme-challenge.sub, oder?

Meinst du damit, dass das ganze dann wie folgt konfiguriert werden müsste - was würde dann bei Destination reinkommen:

Host: _acme-challenge.sub

Type: TXT

Destination: ?

Danke für eure Hilfe

Zitat von DooDafiit

Gute Frage. Weißt du, wie ich das in Netcup und im Proxy Manager einrichten muss?

In diesem Fall hat netcup mit der HTTP-Challenge nichts zu tun. Das ist allein die Aufgabe des Proxy Managers. Von dem habe ich aber keine Ahnung.

Lies dich doch mal hier ein: https://letsencrypt.org/de/docs/challenge-types/

Damit bekommst du dann ein grobes Verständnis, was bei welcher Challenge passiert.

Zitat von Virinum

In diesem Fall hat netcup mit der HTTP-Challenge nichts zu tun. Das ist allein die Aufgabe des Proxy Managers. Von dem habe ich aber keine Ahnung.

Lies dich doch mal hier ein: https://letsencrypt.org/de/docs/challenge-types/

Damit bekommst du dann ein grobes Verständnis, was bei welcher Challenge passiert.

Okay, danke, das werde ich tun.

Mal eine Grundlegende Frage: muss ich diese Subdomain explizit in Netcup anlegen, wenn ich diese bspw. nur für meinen Anwendungsfall verwende? Eigentlich nicht, oder? Und brauche ich in Netcup selbst ein SSL Zertifikat für diese Domain oder ist das sowieso hinfällig, da diese Domain sowieso woanders (IP der FRITZ!Box bspw) hingeht? Habe hier und da noch etwas Verständnisprobleme, wie ihr sicherlich merkt.

Zitat von hoedlmoser

vor allem muss in diesen TXT record die challenge.

Aber ist es grundsätzlich bei der DNS-Challenge vom NGINX Proxy Manager nicht genau das, dass er eben automatisch diese TXT Records anlegt? Oder verstehe ich das falsch?

Zitat von DooDafiit

Mal eine Grundlegende Frage: muss ich diese Subdomain explizit in Netcup anlegen, wenn ich diese bspw. nur für meinen Anwendungsfall verwende? Eigentlich nicht, oder? Und brauche ich in Netcup selbst ein SSL Zertifikat für diese Domain oder ist das sowieso hinfällig, da diese Domain sowieso woanders (IP der FRITZ!Box bspw) hingeht? Habe hier und da noch etwas Verständnisprobleme, wie ihr sicherlich merkt.

Du hast also neben der Domain auch ein Webhosting hier? Nein, im Webhosting musst du gar nichts anlegen. Weder die Domain selber, noch ein Zertifikat. Sobald du im DNS eine abweichende IP-Adresse einträgst, ist das dahinter liegende Ziel für alles zuständig. Dein Webhosting hat mit der Domain dann nichts mehr zu tun.

Zitat von DooDafiit

NGINX Proxy Manager nicht genau das, dass er eben automatisch diese TXT Records anlegt

kannst Du dort netcup als DNS Provider auswählen?

Es kann sein, dass der Proxy Manager nicht lange genug wartet, weil die Netcup DNS-Server nur alle 10min (stimmt das?) aktualisieren. Du musst den Request Timeout vermutlich entsprechend hochdrehen.

Ich hatte das "Problem" auch, bin aber direkt zu einem anderen DNS-Anbieter.

Zitat von Nudelsalat

Du musst den Request Timeout vermutlich entsprechend hochdrehen.

dürft sich propagation delay nennen: https://github.com/NginxProxyM…10#issuecomment-724734616

Zitat von Nudelsalat

nur alle 10min (stimmt das?)

ja. Delay von 10 Minuten klappt reibungslos.

Tatsächlich, das war es auch. Witzigerweise hängt sich das Webinterface vom Proxy Manager nach ein paar Minuten auf und spuckt leere Fehlermeldungen aus. Aber laut Log lief alles noch weiter und letztendlich hat's dann doch noch geklappt.

Danke euch allen