mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 01:15:51 +03:00
[GH-ISSUE #180] Internal error on SSL certificates #157
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#157
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 @IIPoliII on GitHub (Jul 29, 2019).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/180
I tried to add new SSL certificates and i go this issue when try to generate it :
it was working perfectly fine 2 days ago i pulled the last container and for some reason i got this message (unhealthy) with
docker ps@IIPoliII commented on GitHub (Jul 29, 2019):
I founded this is docker inspect looks like something is blocking curl wich should not be the case
@IIPoliII commented on GitHub (Jul 29, 2019):
When trying to ping my own ip on port 9876 (docker proxy i get this)
( founded there https://github.com/EOSIO/eosio-project-demux-example/issues/25)
@IIPoliII commented on GitHub (Jul 29, 2019):
I finnaly went back to another snapshot i think the issue was that i auto run the container but if i am right it already does it ?
https://askubuntu.com/questions/620930/how-do-i-autostart-docker-container-at-system-reboot
I let this issue open in case someone has the same issue and Jc is willing to give a look at it c:
@IIPoliII commented on GitHub (Jul 29, 2019):
Okay i said nothing it did it again and i founded what is the issue. So basiclly create a new proxy host "Request a new SSL certificate". Then confirm, once you have done it remodify the host and add some more domaine, subdomain and go back in ssl certificates and "Request a new SSL certificate" save it and there it is the internal error.
@IIPoliII commented on GitHub (Jul 29, 2019):
After that it's impossible to use let's encrypt ever again in an ways
@s4b3rt0oth commented on GitHub (Aug 7, 2019):
I ran into this issue just today. I proceeded under the assumption that it was a bug.
While reviewing the docker logs I noticed it was looking for "npm-4" and "npm-5", but it couldn't find them. Eventually I came around to deleting the error SSL and remaking the proxy host, requesting the SSL again.
When you view docker logs what do they contain?
@Wadera commented on GitHub (Aug 22, 2019):
I've got the same issue.
There is definitely a bug with Let's Encrypt certs.
Currently my Enginx Proxy Manager works only on port 81 (so I've got access to panel). Whatever I try to change - I've got internal error (but after web page refresh changes looks like saved). Unfortunately all my web traffic is dead now regarding to this issue :(
@Wadera commented on GitHub (Aug 22, 2019):
I've managed to make it running by simple copying any other cert on place where script looking for and everything start's working:
@IIPoliII commented on GitHub (Aug 23, 2019):
Can you explain me what you did exactly and it's working now ? (Also i am a noob in docker so if you could provide the command to access the docker shell with it would be really nice from you c: !)
@Wadera commented on GitHub (Aug 23, 2019):
I've used Portainer (Docker GUI), but you can do it running bellowed command on your node server:
To list all docker containers:
To enter into container:
Then inside just go into
/etc/letsencrypt/livedirectories and copy any other certificate on place of missing one.You can also do it on volume level as letsencrypt directories should be keep outside dicker container.
On default config:
@IIPoliII commented on GitHub (Aug 23, 2019):
I see intressting thanks ! i hope @jc21 see this so maybe he can foudn a fix for it
@EpicLPer commented on GitHub (Oct 15, 2019):
Yup, just got the same issue.
Has anyone found a fix yet that doesn't involve messing with the container itself? I'm not at all familiar with Docker, I'm happy that I got it running somehow haha :)
Let's ping @jc21 again to see if it helps ;)
@bpjobin commented on GitHub (Oct 23, 2019):
Same here. Running on docker as well.
@Shurov commented on GitHub (Nov 11, 2019):
same, but I have problems with NAT Loopback (because of my router). Could this be an issue?
@Wadera commented on GitHub (Nov 11, 2019):
I've didn't check my logs deeply when it occur, but it can be a case (I'm using it on home configuration and behind of home router as well).
@theDwiz01 commented on GitHub (Nov 16, 2019):
Same issues as above. Don't know Docker - friend setup for me. Worked forever but had to re-image OS drive (All Virtual stuff through HyperV and none of this was even on OS drive). After that nothing works. I try to delete all hosts and SSL certs and just get "Internal Error" for everything. Hoping somebody posts some things to try / command to fix
@EpicLPer commented on GitHub (Nov 23, 2019):
I think I found the issue. When the URL you gave it isn't reachable it'll act as if everything worked instead of telling you what went wrong. I accidentally gave it an URL that hadn't been configured properly yet.
@lachlan334 commented on GitHub (Feb 21, 2020):
I started having this same issue yesterday after updating to 2.1.0. Rolling back to 2.0.14 seems to have fixed it.
@jc21 commented on GitHub (Feb 21, 2020):
@lachlan334 it would be nice to know why it failed, the docker logs would have the info. FWIW I'm using 2.1.0 in production and not having these problems.
@SAOPP commented on GitHub (Feb 21, 2020):
Guys, I also have unhealthy status of npm-container, but it's works... what will be the recommendations?
@lachlan334 commented on GitHub (Feb 21, 2020):
The output I'm getting from the health check is
% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (7) Failed to connect to localhost port 9876: Connection refusedLogs are as follows:
@SAOPP commented on GitHub (Feb 21, 2020):
@lachlan334 hey buddy I have the same.. but npm is working fine.
@GregHilston commented on GitHub (Feb 21, 2020):
If it means anything, I've been getting this error with version 2.0.14 running the docker image jlesage/nginx-proxy-manager
@jc21 commented on GitHub (Feb 23, 2020):
@GregHilston Yep that means a lot. I don't maintain
jlesage's images. We're up to 2.1.1 now and port9876isn't used internally anymore.@lachlan334 Looks like you were using that 2.1.1 image, but it doesn't make sense why the Healthcheck is still using a setting from a previous docker image. The correct healthcheck will eventually run a curl command:
curl --silent http://127.0.0.1:81/api/from within the NPM container.Perhaps try pulling down the stack entirely and putting it back up, assuming your have directory mounted volumes:
docker-compose down && docker-compose up -d@0ShinyNinetales0 commented on GitHub (Feb 24, 2020):
I'm running into a similar problem. Requesting a new SSL certificate generates an Internal Error.
Inspecting the docker container shows it's unhealthy and it's spitting some errors:
`
[
`
Here I saw the connection refused on 9876, not knowing what's causing it.
I'm using jc21's image, running version 2.1.1.
I don't mean to hijack, but perhaps this is the same problem as OP's running into.
EDIT: Code formatting
@f0b04707 commented on GitHub (Feb 26, 2020):
Same here ! Using jc21's image, version 2.1.1, on docker bridge.
EDIT: deleting the container and creating a new one from scratch did fix it though.
@jc21 commented on GitHub (Feb 26, 2020):
Not sure if it's a docker bug or expected behaviour but it feels like upgrading a docker image within an already-created container, doesn't update the healthcheck. There were quite a few changes between 2.0.* and 2.1.* of NPM so I recommend bringing down the stack entirely and recreating it.
Using existing
dataandletsencryptdata mounts will be fine though.@jc21 commented on GitHub (Feb 26, 2020):
That said, the healthcheck shouldn't affect the ability for a certificate to be renewed.
@0ShinyNinetales0 commented on GitHub (Feb 27, 2020):
Thank you for the reply jc21.
I don't know about the other users, but in my case this is a clean container / image of version 2.1.1.
I have recreated it once with re-using the data and let's encrypt folder. But the obtaining of SSL certificates never worked.
I eventually gave up on it and used my synology nas to retreive certificates and manually importing them into Nginx, which worked fine.
But it would be nice to find out why the internal error occurs and why the log is spamming the connection refusal on port 9876.
Is there anything I can submit that could help you give insight on the situation?
Kind regards.
@shanecasey commented on GitHub (Feb 27, 2020):
I'm getting the same error and unhealthy status in Docker. I have had the error message pop in the past but at the moment I can still create new certs. I tried deleting the old certs and recreating them but always have the same unhealthy container :(
Outputs from my container below if it helps
Docker:
Logs:
@jc21 commented on GitHub (Feb 27, 2020):
There is a
github-developdocker image that has removed 9876 from the Dockerfile EXPOSE. This was the last trace of this port in the entire codebase and although the 2.1.* images should not be using this port whatsoever, for some reasons that apply to specific people it might make a difference.So, use the
github-developimage tag, make sure the previous container is entirely removed before creating a new one. I'll mention the steps here for anyone who doesn't know:docker rm -f name_of_nginx_proxy_manager_containeror
docker-compose downIf there is any trace of this port 9876 in your healthchecks after that, then I'll literally flip my desk and rage quit this project.
@0ShinyNinetales0 commented on GitHub (Feb 28, 2020):
Removing the container and setting up a new one using the
github-developimage solved the internal error when requesting SSL certificates for me.I can see port 9876 is no longer used by this image as well.
I just managed to get Let's Encrypt certificates for all my proxy hosts directly trough Nginx, what a blessing!
Currently I'm unable to SSH to my device (only allowed from local network and I'm at the office right now), so when I am back home I will check the docker container health status. Will get back to you!
@AnonJervis commented on GitHub (Feb 28, 2020):
Can confirm!
Used
github-developimage and the container becomes healthy again with port 9876 no longer used anymore! I've tried it on 3 different hosts and containers are no longer unhealthy.@0ShinyNinetales0 commented on GitHub (Feb 28, 2020):
I just got home and checked trough SSH what the docker container's health status is. It's looking perfectly fine!
Health": {
"Status": "healthy",
"FailingStreak": 0,
No need to flip the desk and rage quit the project @jc21 ;)
@shanecasey commented on GitHub (Feb 28, 2020):
I nuked my container and rebuilt with github-develop and mine is happy and healthy now too. Thanks!
@lachlan334 commented on GitHub (Feb 29, 2020):
Can also confirm that using the
github-developimage fixed the issue.@brantje commented on GitHub (Mar 3, 2020):
Yep, after removing the container and using the
github-dockerimage, the certs where updated automatically.@jc21 commented on GitHub (Mar 6, 2020):
Ok sweet I'll merge and re-release today. Phew :)
@SAOPP commented on GitHub (Mar 10, 2020):
So guys, what I need to do? Use the develop of the container? 'Coz I have unhealthy still. Thanks in advance.
@nldoty commented on GitHub (Mar 10, 2020):
@SAOPP unhealthy typically means the container took more than 5 seconds to return an OK status. If you're able to create new SSL certificates, you should be good to go. The unhealthy status isn't a big deal.
@SAOPP commented on GitHub (Mar 10, 2020):
Yes I understood it, just interesting, and yes I can create a new certs, but I see guys talked about not possible auto renewal certs or I misunderstood?
@Foxglove-X commented on GitHub (Mar 15, 2020):
Please forgive my being uninformed on Docker, but when will this get pushed out to places like Dockerhub? I'm using an Unraid environment.
Is there a way I can upload and use my own certificate in the meantime, such as a Cloudflare certificate?
@nldoty commented on GitHub (Mar 15, 2020):
@Foxglove-X I believe it was already pushed about 4 days ago.
Check the tags under the Docker Hub page.
https://hub.docker.com/r/jc21/nginx-proxy-manager/tags
@Foxglove-X commented on GitHub (Mar 15, 2020):
Ah I see! Mine was pulled from jlesage/nginx-proxy-manager/ which is 5 months out of date.
That must be some other Docker image that's not as well maintained. I should probably use this one instead. Thank you.
@jc21 commented on GitHub (Mar 15, 2020):
jlesage will have to update his own docker images each time I release mine. I don't have an unraid setup myself so I don't know what changes are required to make it work
@rto54 commented on GitHub (Apr 7, 2020):
Hello,
I just installed the latest version of npm.
docker-compose.yml
config.json
I tried to add new SSL certificates and i go this issue when try to generate it :
I have
Thank for all
@nldoty commented on GitHub (Apr 7, 2020):
@rto54 without the logs from the docker containers themselves, there's not a whole lot anyone can debug. Can you provide them?
@rto54 commented on GitHub (Apr 7, 2020):
@nldoty, You can help me for this.
I am a beginner with the docker :-(
Thank
@rto54 commented on GitHub (Apr 7, 2020):
@rto54 commented on GitHub (Apr 7, 2020):
Logs letsencrypt
@Nornode commented on GitHub (Apr 17, 2020):
I seem to have a very similar issue...
I had the issue prior to pulling the latest image too
docker logs nginx_proxy
container-start.sh
docker image inspect jc21/nginx-proxy-manager:latest
logs in container:
(/var/log/letsencrypt/letsencrypt.log)
Let me know if there are any other information missing from above.
@mike-ford-igt commented on GitHub (May 4, 2020):
Not sure if anyone else has run into this. I'm running the proxy container on VM inside corporate network and when I try and create the proxy in Nginx Proxy Manager, I too get the 'Internal Error' and in the log I can see that lets encrypt can't validate my domain. Under SSL Certificates there is an entry but its immediately expired. In the DNS Manager we use I have my domain mapped to the host IP of the machine where I'm running the proxy container in the Forward Lookup Zone. Am I correct in thinking letsencrypt just can't reach my domain to validate that 'I own it'?
2020-05-04 17:10:39,713:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/4362994539 HTTP/1.1" 200 625
2020-05-04 17:10:39,714:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Mon, 04 May 2020 17:11:21 GMT
Content-Type: application/json
Content-Length: 625
Connection: keep-alive
Boulder-Requester: 85028888
Cache-Control: public, max-age=0, no-cache
Link: https://acme-v02.api.letsencrypt.org/directory;rel="index"
Replay-Nonce: 0002Z8epRT7DdbUiCHQ6gsOQuvNlarPnL7KRDGYsEg7qoCM
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
{
"identifier": {
"type": "dns",
"value": ""
},
"status": "invalid",
"expires": "2020-05-11T17:11:19Z",
"challenges": [
{
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: NXDOMAIN looking up A for - check that a DNS record exists for this domain",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/4362994539/zHEy1w",
"token": "PCdm1kOKDDqyzF4LX6-gAt0omNYuV0iwRNBtQ0NLR5Q"
}
]
}
@s4b3rt0oth commented on GitHub (May 4, 2020):
@jmford775 Yes, you are correct. Letsencrypt requires you to verify ownership of a domain before issuing a certificate. It does this by first looking for a valid domain response, then reaching out to the domain to verify the server is sitting there. For this to happen you will need to point the domain to the IP you plan on using and open port 80 on that IP and have it point to your proxy container.
From the sound of your post you plan on using this internally. Note that setting up internal DNS to point to your machine will not be sufficient. There must be a valid public IP address with matching DNS pointed to your container. Likewise, the certificate will be valid ONLY for that external address and will not work internally (unless you utilize the same naming scheme).
For example:
External Public IP: 1.1.1.x
Internal Public IP: 10.0.10.x
Public DNS: public.com
Internal DNS: internal.com
Your container sits on 10.0.10.y and it requests a certificate for container.internal.com. Letsencrypt does not know where your container is, because it is using an internal DNS schema. If you request container.public.com then letsencrypt will be able to see that you pointed container.public.com to your external IP (1.1.1.x) and will reach out to that IP (Port 80 [forwarded on firewall]) to verify that the container is actually sitting there.
@AnonJervis commented on GitHub (May 5, 2020):
@s4b3rt0oth I have the same problem as @jmford775 but mine is to connect from the outside. My port 80 and 443 are open and pointing to NPM server but it still shows internal error. The exact same thing happened to me where once trying to add SSL cert, it shows "Internal Error" and will show the cert expired same date and time when I tried adding.
@bpjobin commented on GitHub (May 5, 2020):
Same here. Running the github-develop build.
Sent from my iPhone
@mike-ford-igt commented on GitHub (May 5, 2020):
@s4b3rt0oth Yeah I realized it was going to be a no-go being inside our corporate network and thanks for the reply. I decided since we are already behind super strict firewalls that I would just run a no-auth registry and joxit ui
@lhend941 commented on GitHub (Sep 8, 2020):
Same thing here. Using the Nginx Proxy Manager Add On for Home Assistant
@vinhmh commented on GitHub (Mar 14, 2021):
are you change expose port of npm app difference 80 ?
@postmaster11 commented on GitHub (Jul 30, 2021):
Got the same issue... I have 4 proxy-hosts, only one is unable to get a new certificate. Finally ended up in NGINX logs where I found that NGINX is not able to fire up the webserver for verification (cannot bind IP-address to port 80).
After comparing this NPM container with another one, I found that I changed the Docker-network from 172.... to 10.10.0.0. It's possible that I changed this after deploying the first proxy-host. I guess the old IP or subnet is still somewhere in NGINX configfiles - does somebody have an idea where? I'm not really used with NGINX...
@MarkIvanowich commented on GitHub (Aug 16, 2021):
Strangely, I had certs reporting as expired, but the browser was reporting up-to-date certificates. One of my certs was disconnected for a while, so of course it's cert didn't renew. Connecting and trying to renew showed me this internal error.
I restarted my docker containers, then changed the 'default site' option in settings to 'custom page'. It was previously set to '404 page'. I was thinking that the 404 was returned before the challenge file, interfering with renewals.
When I looked at the certificate page, all my certs were up-to-date. So I'm not sure if it was the container reboot, or if it was changing the 'default site' option that solved my problem. Give it a try?
@pgk83 commented on GitHub (Sep 19, 2021):
Same issue here, i change the Default Site from Congratulations Page to Redirect and i give internal error on cert renew. i think npm redirect the request before the certbot find the /.well-known/-acme-chellenge/
i change it back for congrat page but i have a same erreor...
@Foxglove-X commented on GitHub (Sep 19, 2021):
I had this problem at one point. I use CloudFlare DNS, and I was able to resolve by disabling CloudFlare's proxy.
There was not much helpful error information when the certificate generation failed, but I could confirm I had the issue anytime proxy was enabled, issue resolved once it was disabled.
@archef2000 commented on GitHub (Oct 16, 2021):
it has to do with the dns it cant resolve the url just set your own dns server in /etc/resolv.conf or in docker-compose
dns:
-172.17.0.1
-172.20.0.1 (for me)
@chaptergy commented on GitHub (Oct 25, 2021):
As this issue is very old, there have been huge changes in how certificates work since then. And as "Internal error" is just a generic error and does not provide any information about the actual error, all newer reports probably have nothing to do with the original issue reported in this ticket. To prevent people from posting "I see an internal error too", I will close and lock this issue. If you encounter any problems please look for other issues describing the same issue as you have, or if you can't find any, open a new issue. Include as much information as possible in this new issue like logs. Also see https://github.com/jc21/nginx-proxy-manager/issues/1271 for more information.