mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 17:35:52 +03:00
[GH-ISSUE #2201] Netcup DNS challange fails #1577
Labels
No labels
awaiting feedback
bug
cannot reproduce
dns provider request
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
need more info
no certbot plugin available
product-support
pull-request
question
stale
troll
upstream issue
v2
v2
v2
v3
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-proxy-manager-NginxProxyManager#1577
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zinnchen on GitHub (Aug 16, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2201
Checklist
jc21/nginx-proxy-manager:latestdocker image?Describe the bug
I try to create a let's encrypt certificate via DNS challange on netcup.
npm/certbot creates the TXT record for domain successfully.
BUT the problem ist, that the name of the TXT record which is created by npm is not the same as the one expected by certbot.
Let's say I want to create a cert for test.mydomain.com, a TXT record with name '_acme-challenge.test' is created in netcup DNS section of mydomain.com.
The problem is, that acme client is looking for a TXT record with name '_acme-challenge.test.mydomain.com' which of course fails.
Extract of letsencrypt log:
"detail": "DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.mydomain.com - check that a DNS record exists for this domain",Nginx Proxy Manager Version
v2.9.18
To Reproduce
Steps to reproduce the behavior:
** Log Entries **
*** npm log ***
lertsencrypt log
Expected behavior
the certificate is created successfully
Screenshots
none
Operating System
unraid
Additional context
none
@the1ts commented on GitHub (Aug 16, 2022):
I don't think the DNS problem is that its adding in the domain in one location (NPM) and not when in the DNS provider. When in the DNS provider, the .mydomain.com is added by default since that is the DNS zonefile you are in.
I think since the start of your log and the end of your log is only 34 seconds, the DNS entry is not getting into the DNS servers in time for letsencrypt to find them before the time out expires and its abandoned. I suggest you add a value of 60 or 120 into the propagation seconds to allow netcup longer to get the DNS entry from the web api to the DNS sever.
@zinnchen commented on GitHub (Aug 16, 2022):
@the1ts thanks for the fast feedback.
I already tried 120 (and much more) seconds in some tests before.
In these cases I saw the TXT entry in the netcup webUI. But always the short term:
_acme-challenge.testI checked with 120s again, but without success (and same error)
@the1ts commented on GitHub (Aug 16, 2022):
Taking a look at the certbot-dns-netcup, there its recommended to use 600+, seems netcup have a hugely slow DNS update process.
@zinnchen commented on GitHub (Aug 16, 2022):
wow, that (700s) worked. Thank you so much @the1ts.
I couldn't imagine netcup is that slow.