mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 17:35:52 +03:00
[GH-ISSUE #51] Not passing letsencrypt requests through proxy_host #47
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#47
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 @xorinzor on GitHub (Jan 12, 2019).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/51
From my own testing it seems that the /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf rules prevents access to the letsencrypt tokens/acme-challenges of any hosts configured as proxy_host.
This is probably because it's trying to access it's own letsencrypt challenges, which ofcourse isn't going to work.
If this isn't something that can be fixed to be allowed for proxy_hosts, can it be disabled in the meanwhile?
It will currently prevent my services of renewing it's certificate when the Nginx-proxy-manager docker container is going to update (and I forget to "fix"/disable the letsencrypt rules).
Alternatively, a way of making these config files persistent would be great too.
EDIT: I just noticed that doing this prevents the proxy-manager from updating it's letsencrypt certificates..
@xorinzor commented on GitHub (Jan 12, 2019):
I've been trying to adjust the config file myself, to check if the requested file exists locally before using proxy_pass. But for some reason I can't properly test it because it will always return a 404 on a file that I put in the /config/letsencrypt-acme-challenge directory. Even with the default config file source.
Double checked the permissions too. Almost feel like there's something else going on whenever the nginx-manager updates the certificate.
Would very much appreciate it if you could realize this.
@jc21 commented on GitHub (Jan 14, 2019):
The project was not designed for people who want 2 or more letsencrypt services on their network.
We need to capture all acme requests because there may be hosts in the project that are disabled or deleted, but their Certificates still exist and get automatically renewed.
I don't know the reasons for you to want multiple SSL terminated services on the same IP but this project might not be for you if that is a requirement.
@xorinzor commented on GitHub (Jan 27, 2019):
The reason I want multiple SSL is because the proxy manager only uses SSL to be able to proxy https requests too.
However, the services that run behind the web interface will still need their own certificates renewed to be properly used (ie: poste.io mailserver) on different ports that also use SSL encryption.
IMO hosts that are disabled or deleted shouldn't be managed by the proxy manager, active hosts should take priority, and the requests should be passed on if they aren't meant for the proxy manager.
I need the proxy manager because I need the reverse-proxy in order to be able to run multiple services behind the same port 80 / 443.
@xorinzor commented on GitHub (Feb 5, 2019):
For the moment I fixed this for me by configuring it to HTTP only, given that I block pretty much everything except letsencrypt for this particular service at this moment.
I still stand by my previous point though.
@jc21 commented on GitHub (Feb 6, 2019):
Passed on to what? If your domain points to the IP of the machine that is running this project, you can't pick and choose which TCP connections go where, that's why there's a HTTP layer. So, if you delete a host, but it still points to 80/443 running this project, it will say "oh you want example.com? I can't give you that" so it gives you the "Congratulations" page as a default, because we don't know where to send the request since you deleted the configuration for it.
I still stand by my previous point, this project may not be for you. You want a specific implementation and you're the only one wanting it.
@vibratim commented on GitHub (Jan 14, 2020):
I am trying exactly the same atm. My poste.io mailserver needs to create its own certificate via Let's Encrypt (which kind of worked with a custom location for the mailserver entry) and if this works the http/s would not get through.
Option 2 is giving the poste.io container the certificate files, but i am not sure where to find them etc.