mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-26 01:45:54 +03:00
[GH-ISSUE #1482] Yet another "Failed to renew SSL" issue #1138
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#1138
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 @dl-lim on GitHub (Oct 13, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1482
Hi there, I'm using the official docker image, version 2.9.7
I've looked for many other similar instances of SSL certbot not working correctly, but haven't come across a solution for my case yet. Please do point out the right issue # if I've missed them.
So, I've been using this for a while now, so am not new to the project, and I've always had problems with certbot renewing.
Ports are correctly forwarded externally so no issue there. I've also been using Cloudflare as an additional layer to anonymise my IP + DDoS protection. I use Cloudflare's DNS service and also DDNS (where I use another service to automatically update my external IP address to Cloudflare)
I think Cloudflare would have been the problem when renewing certs, so I have disabled them temporarily to test renewing, but it still fails with the following logs.
The only approach I haven't tested is deleting all the certs and recreating them, because I have so many! A feature to do this in bulk would be much appreciated, but that's beside the point :)
So, back to the logs, what is immediately obvious?
I'd thought that
Temporary failure in name resolutionmeant it's not reachingacme-v02.api.letsencrypt.orgbut this is not true, since I am able to ping it successfully from the machine hosting Nginx Proxy Manager.Any thoughts?
On other occcassions, I'd get internal errors or timeouts too. Can't make any further changes, so I would
docker-compose downanddocker-compose up -dagain to "reset" the app.Generally, can't renew cert without error, and it is only by luck that it gets renewed successfully.
Most of the certs are shown as expired on the web UI, but https still works on the underlying reverse-proxied application
What can I do about this and what is a good practice to prevent this from happening?
@chaptergy commented on GitHub (Oct 13, 2021):
Yeah, unfortunately certbot does have a number of issues which we can't do anything about, except to switch to a different tool to generate certificates, which is planned for v3.
Concerning some of the questions you asked:
Another instance of Certbot is already running., see https://github.com/jc21/nginx-proxy-manager/issues/918#issuecomment-942486719 on how to fix this.Temporary failure in name resolutioncould mean that either certbot is not able to connect to the letsencrypt acme servers, or that they were not able to connect back to the webhost on port 80 to confirm you have control over this domain (depending on the context). Cloudflare is also often a source of issues. If you disable cloudflare you are able to access your proxied apps from the outside on port 80?The certbot output in the normal docker lock is usually very limited and does not provide much useful information. The letsencrypt logs contain much more information, which would be useful to find the source of the problem. See https://github.com/jc21/nginx-proxy-manager/issues/1271#user-content-certificate-error on how to access these logs.
@dl-lim commented on GitHub (Oct 14, 2021):
@chaptergy firstly, thanks a bunch for your detailed writeup, really appreciated.
How close are we to this? We're at 2.9.9, so must be close? :D
Thanks. I noted this one. Fixing it usually still leads to timeout.
Yeah, this makes sense. The https still works without error on browser side, but it's just all wrong in the Web UI.
I know this is a DNS issue, sometimes even on client side, but I've triple checked to make sure internet access is connected. Without cloudflare proxy, my external IP ports are all forwarded correctly and can associated domains be reached thanks to Nginx Proxy Manager. I've had cloudflare proxy turned on in production and it didn't have issues with DNS previously. I turned it off to troubleshoot this.
Here they are:
letsencrypt.log
@chaptergy commented on GitHub (Oct 14, 2021):
Unfortunately v3 is still a while away I think, there is no official timeline yet.
Hm, but the logs also only contain the error that it fails to connect to acme-v02.api.letsencrypt.org, or rather it fails to resolve the domain. But you said you are able to ping it? So you have installed ping within the npm container and are able to ping the domain? Are you also able to run
nslookup acme-v02.api.letsencrypt.org(ypu'll need to install thednsutilspackage fornslookup?@dl-lim commented on GitHub (Oct 20, 2021):
Hrmm, now that you mention doing this, I'm not even able to
apt updateinside the docker container since it doesn't even reach the Internet, looks like...Because of that, couldn't even install ping
Any ideas? I could ping just fine from the host machine.
I've also recreated this container several times. Only thing that persisted was the volumes.
@chaptergy commented on GitHub (Oct 20, 2021):
It seems this is actually an issue with your installation of docker. As this could be caused by many things and has nothing to do with npm, I will close this issue.
Depending on what OS you used, how you installed docker, etc, you should be able to find articles and questions with similar issues which will help you with your issue.
Some links to get started: