mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 09:25:55 +03:00
[GH-ISSUE #1706] Internal Error with netcup and DNS Challenge #1268
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#1268
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 @TWART016 on GitHub (Dec 30, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1706
Describe the bug
I want to access my internal password management (vaultwarden) with NPM. Therefore I created in Netcup an A-Record with Destination my internal IP 192.168.178.15. Also I added a TXT entry with Destination: pw-local.MYDOMAIN.
In NPM I created a proxy host and Forward to my password management. In SSL I want to create a certificate with Use a
DNS Challenge. I selected netcup as the provider and set dns_netcup_customer_id , dns_netcup_api_key and dns_netcup_api_password. After save I get aInternal ErrorMessage.In Docker Logs I see
Inside letsencrypt.log:
"Incorrect TXT record \"pw-local.mydomain.de\" found at _acme-challenge.pw-local.mydomain.de",Nginx Proxy Manager Version
2.9.13
Operating System
Ubuntu 18.04.4 LTS (Bionic Beaver) with Docker
Edit: If I add the domain to an other proxy host in NGINX the website can be opend but of couse with an certificate error.
Without a certificate it is not possible to access the website.
@chaptergy commented on GitHub (Dec 30, 2021):
What do the certbot logs say? (see https://github.com/jc21/nginx-proxy-manager/issues/1271#user-content-certificate-error)
@TWART016 commented on GitHub (Dec 30, 2021):
Do you mean the log from /var/log/letsencrypt/letsencrypt.log ?
@chaptergy commented on GitHub (Dec 30, 2021):
Yes.
@TWART016 commented on GitHub (Dec 30, 2021):
Here is the log
Is the destination in Netcup correct pw-local.MYDOMAIN? Do I need a token there?
@chaptergy commented on GitHub (Jan 1, 2022):
Hm, it's weird that it is an incorrect TXT record and not just no record at all. Have you tried increasing the propagation seconds? By default they seem to be just 10 seconds which might not be enough.
@TWART016 commented on GitHub (Jan 1, 2022):
I set propagation to 300 seconds but it runs into a timeout.
What should be the TXT record look like?
@sumadark commented on GitHub (Jan 13, 2022):
Hi everybody,
I have a similar issue, trying to get a new certificate for a subdomainn here is the content of letsencrypt.log :
Here is my docker compose :
If someone has an idea about this issue, I would be very glad to read it. Thanks !
@chaptergy commented on GitHub (Jan 13, 2022):
@sumadark Your problem has nothing to do with the problem discussed in this issue, you are not even using netcup as the domain provider. And I'm pretty sure your issue is due to your own custom
letsencrypt.iniand maybe in conjunction with thecloudflare.ini, not sure what that is for. Though we cannot provide support for that.@sumadark commented on GitHub (Jan 13, 2022):
Thanks for your reply...
@nickibyte commented on GitHub (Mar 3, 2022):
This might be a bit late, but for the sake of maybe closing the issue here is what I found when fixing a similar problem with the DNS challenge for the provider netcup:
I believe the reason the DNS challenge failed with the "Incorrect TXT record" error is that @TWART016 manually created the
_acme-challenge.pw-local.mydomain.deTXT record with the destinationpw-local.MYDOMAIN. This record will be automatically created by certbot with a string it gets from Let's Encrypt as the destination and will be deleted after the DNS challenge has been completed. That is why the API key and password are needed, to create/delete this TXT record.So to fix the issue with the DNS challenge:
_acme-challenge.pw-local.mydomain.deTXT record480(this number worked for me, the default was way to short and I got a "No TXT record" error)After 8-10 minutes you should have your certificate.
@LukasOchmann commented on GitHub (Mar 26, 2023):
I have an simular issue, and i tried to set the propagation 480 but that runs in a timeout then ... Is there a way to increase the timeout?
I can see that certbot is createing the
__acme-challenge.<subdomain>as a TXT record in netcup.@LukasOchmann commented on GitHub (Mar 26, 2023):
The Content of the log-file
/var/log/letsencrypt/letsencrypt.log:@bernhardkaindl commented on GitHub (Nov 15, 2023):
Same here. I opened https://github.com/coldfix/certbot-dns-netcup/issues/28 to let https://github.com/coldfix/certbot-dns-netcup pick a default time which should work. I needs to be above 600 as the zone reload time of Netcup is 10 Minutes, confirmed by many in Netcup's customer forum.
@LukasOchmann https://pypi.org/project/certbot-dns-netcup/ says at least 600 seconds is needed for Netcup (and likely even then may need some tries), and 900 seconds should really work.
On the Nginx-proxy-manager side, the Nginx-proxy-manager Web UI should be fixed to not time out after just a minute to allow for longer DNS Challenge propagation times:
Currently, it shows a red error bar long before that, but
certbotthankfully continue to wait for 900 seconds and finishes its work.While waiting, to check the status, you can open a shell in the container and run
tail -f /tmp/letsencrypt-log/letsencrypt.logAfter you see the successfully
certbotcompletion in the log, just reload the Nginx Proxy Manager web UI and you should see your proxy asOnline.https://github.com/coldfix/certbot-dns-netcup
See https://github.com/coldfix/certbot-dns-netcup/issues/28
Update: As confirmed in German forum discussions in forum.netcup.de, the observation of customers is that Netcup runs the actual DNS zone updates every 15 minutes, apparently on a cron-like schedule each hour, seemingly like starting at minute
00,15,30and45.@github-actions[bot] commented on GitHub (Jun 26, 2024):
Issue is now considered stale. If you want to keep it open, please comment 👍
@github-actions[bot] commented on GitHub (Apr 13, 2025):
Issue is now considered stale. If you want to keep it open, please comment 👍
@bernhardkaindl commented on GitHub (Jul 24, 2025):
This should be fixed with #28.
@github-actions[bot] commented on GitHub (Feb 21, 2026):
Issue is now considered stale. If you want to keep it open, please comment 👍