mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 01:15:51 +03:00
[GH-ISSUE #1628] Complete crash when requesting a second wild-card cert from GoDaddy with DNS #1222
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#1222
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 @JohnGalt1717 on GitHub (Dec 3, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1628
Checklist
jc21/nginx-proxy-manager:latestdocker image?Yes
Yes
Yes - Sort of the same exists but this gives explicit steps and the last one was closed with no repro
Describe the bug
If you try and add a second wild card cert from the SSL tab using go-daddy (not sure if it does this with others) you'll get an internal error about an npm folder in /letsencrypt/live not existing. Anything else you try and do in the session will error although the existing proxies will continue to function. If you restart the container, it will crash on boot. The only way to work around is to copy one of the other npm folders into the one it's looking for in the log and then it will start.
Nginx Proxy Manager Version
2.9.7
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Should add the second certificate without error and not bork nginx manager entirely.
Operating System
Debian Linux
Additional context
❯ /data/nginx/redirection_host/1.conf
nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/npm-8/fullchain.pem": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/letsencrypt/live/npm-8/fullchain.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file)
@chaptergy commented on GitHub (Dec 3, 2021):
Could you please provide the letsencrypt logs (see https://github.com/jc21/nginx-proxy-manager/issues/1271#user-content-certificate-error)
@JohnGalt1717 commented on GitHub (Dec 3, 2021):
I don't think it's in there (because I "fixed" it by copying the directory in) but the one that failed to create the directory etc was npm-8:
@chaptergy commented on GitHub (Dec 3, 2021):
Yeah, as you said there is nothing in there, since this is most likely not the log of when
npm-8was created. If you can replicate the issue please provide the logs of what happens when the error occurs.@JohnGalt1717 commented on GitHub (Dec 3, 2021):
One would assume that it's a pretty straight forward repro though. Sorry I didn't get the logs, but it's a live system with external dependencies so after I reproduced the issue once I fixed it and put it back in production to minimize downtime.
@chaptergy commented on GitHub (Dec 3, 2021):
It is much easier when you actually have a GoDaddy domain :P
Just let me know if you ever run into this issue again and have logs to help debug it.
@JohnGalt1717 commented on GitHub (Dec 3, 2021):
... almost certain it will happen with any DNS verification if you just do 2 separate wildcards....
@chaptergy commented on GitHub (Dec 3, 2021):
Well, I am not able to reproduce it with other providers, requesting multiple wildcard certificates for the same domain, e.g.
*.example.comworks as expected, and restarting npm does not cause it to crash on boot.@the1ts commented on GitHub (Dec 7, 2021):
Yes, can confirm that Hetzner can have multiple wildcard certs for different domains without issues. Checked and the new cert is created fine.
@ch4ox commented on GitHub (Dec 27, 2021):
I once had a similar problem where something like this happened and I had to fix paths in the database manually.
I think the steps I took were 1. creating a wildcard cert (Hetzner), 2. attaching this cert to a host, 3. deleting the cert without updating the host afterwards. A restart finally killed it for good.
Maybe something like that happened here as well?
@tree-white commented on GitHub (Jan 22, 2022):
When I applied for a wildcard certificate, there was an error error, and after I tried to restart, there was a nginx: [emerg] cannot load certificate.
@spuxx-dev commented on GitHub (Nov 8, 2022):
I'm running into the same issue. Did you find a solution @tree-white?
@spuxx-dev commented on GitHub (Nov 8, 2022):
The issue was caused by a proxy_host that was assigned an ssl certificate that had been deleted. I managed to fix it by navigating to the data volume and into /nginx/proxy_host, and deleting the *.conf files that were referring to the deleted certificate.
@tree-white commented on GitHub (Nov 18, 2022):
I forgot after a long time, but in the end I remembered redeployed and only applied for a wildcard certificate.
@github-actions[bot] commented on GitHub (Feb 29, 2024):
Issue is now considered stale. If you want to keep it open, please comment 👍
@PlamenGeorgievKostadinov commented on GitHub (Nov 7, 2024):
same problem here
@github-actions[bot] commented on GitHub (Jun 18, 2025):
Issue is now considered stale. If you want to keep it open, please comment 👍
@JohnGalt1717 commented on GitHub (Jun 18, 2025):
👍
@github-actions[bot] commented on GitHub (Jan 28, 2026):
Issue is now considered stale. If you want to keep it open, please comment 👍