starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 09:25:55 +03:00

Redirect not working with HTTPS #556

New issue

Closed

opened 2026-02-26 06:33:22 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 06:33:22 +03:00

Owner

Originally created by @rezzorix on GitHub (Oct 15, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/657

Hi, this is about an obstacle (error?) I came across when setting the default site in NPM:

Settings -> Default Site -> Redirect not working with HTTPS

Example:
Lets say my WAN IP address which has port 80 open to NPM is 123.123.123.123

The "Default Site" is set to "Redirect to" https://www.google.com (or any other external URL).

When you then open the IP address in a browser the following happens:

http://123.123.123.123 -> successful redirect
https://123.123.123.123 -> certificate error/warning, not redirect

If I understand correctly then the certificate error will come anyway because the IP cannot be secured with a certificate.
However, if the certificate error is ignored in browser... shouldnt then still be a redirect possible?

Originally created by @rezzorix on GitHub (Oct 15, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/657 Hi, this is about an obstacle (error?) I came across when setting the default site in NPM: _Settings -> Default Site -> Redirect not working with HTTPS_ Example: Lets say my WAN IP address which has port 80 open to NPM is 123.123.123.123 The "Default Site" is set to "Redirect to" https://www.google.com (or any other external URL). When you then open the IP address in a browser the following happens: 1. **http**://123.123.123.123 -> successful redirect 2. **https**://123.123.123.123 -> certificate error/warning, not redirect If I understand correctly then the certificate error will come anyway because the IP cannot be secured with a certificate. However, if the certificate error is ignored in browser... shouldnt then still be a redirect possible?

kerem

2026-02-26 06:33:22 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@jc21 commented on GitHub (Oct 15, 2020):

The decision was made not to support this and to instead return a 444. I don't want to support clients that skip SSL security. I can't think of any valid use case to do this for the default site.

@jc21 commented on GitHub (Oct 15, 2020): The decision was made not to support this and to instead return a 444. I don't want to support clients that skip SSL security. I can't think of any valid use case to do this for the default site.

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@rezzorix commented on GitHub (Oct 16, 2020):

Thanks for the quick answer.

Understood. Just as a background why I would use this feature.

I am having subdomains pointed to my WAN IP at home via DDNS...

So if someone is trying to directly enter the WAN IP with http://wan.ip - the NPM is hit with an unknown host and redirected to e.g. Google.

Since most browsers automatically use https:// there would not be a redirect at all, exposing that there might be something other than a redirect...

Anyway, maybe I am thinking about this the wrong way?

@rezzorix commented on GitHub (Oct 16, 2020): Thanks for the quick answer. Understood. Just as a background why I would use this feature. I am having subdomains pointed to my WAN IP at home via DDNS... So if someone is trying to directly enter the WAN IP with http://wan.ip - the NPM is hit with an unknown host and redirected to e.g. Google. Since most browsers automatically use https:// there would not be a redirect at all, exposing that there might be something other than a redirect... Anyway, maybe I am thinking about this the wrong way?

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@jc21 commented on GitHub (Oct 16, 2020):

It's good to think defensively. From an attack point of view though, if port 443 is open then it's a given that there's a https server running on it. An attacker doesn't need to get a SSL cert working or otherwise in order to know that.

So in this case the security of your hosts starts with obscurity, the attacker would need to know the exact DNS names to use.

Let's assume that your DNS names are somehow known to the public either through forums or google search results. I would suggest that everyone assumes this and puts measures in place to protect their hosts further. At the end of the day the last security measures have to come from the hosts that NPM is forwarding to.

@jc21 commented on GitHub (Oct 16, 2020): It's good to think defensively. From an attack point of view though, if port 443 is open then it's a given that there's a https server running on it. An attacker doesn't need to get a SSL cert working or otherwise in order to know that. So in this case the security of your hosts starts with obscurity, the attacker would need to know the exact DNS names to use. Let's assume that your DNS names are somehow known to the public either through forums or google search results. I would suggest that everyone assumes this and puts measures in place to protect their hosts further. At the end of the day the last security measures have to come from the hosts that NPM is forwarding to.

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@ghostersk commented on GitHub (Sep 2, 2021):

I think I have solution for HTTPS Redirect, I created 404 host where i used domain name with wildcard: *.MyDomainName.com
I enabled SSL, unfortunately I use Namecheap provider for DNS and It does not allow me create wildcard certificate, so everytime they must confirm certificate. But now I have custom error page on HTTP and HTTPS, the example bellow points to the Custom Html file what can be created from the Nginx Proxy manager > Settings > Default site: Custom

Just add this bellow to the 404 Hosts for any Domain you want, you can use the Wildcard mentioned (*.domain.com)

 location / {
    root   /data/nginx/default_www;
    index index.html;
    rewrite ^/$ /index.html break;
  }

@ghostersk commented on GitHub (Sep 2, 2021): I think I have solution for HTTPS Redirect, I created 404 host where i used domain name with wildcard: *.MyDomainName.com I enabled SSL, unfortunately I use Namecheap provider for DNS and It does not allow me create wildcard certificate, so everytime they must confirm certificate. But now I have custom error page on HTTP and HTTPS, the example bellow points to the Custom Html file what can be created from the Nginx Proxy manager > Settings > Default site: Custom Just add this bellow to the 404 Hosts for any Domain you want, you can use the Wildcard mentioned (*.domain.com) ``` location / { root /data/nginx/default_www; index index.html; rewrite ^/$ /index.html break; } ```

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@ljlongwing commented on GitHub (Mar 21, 2023):

Do you have suggestions for this scenario, which brought me here today?

I am using Technitium DNS server and am using it primarily for DNS level add blocking. By default when a user on my home network tries to go to a 'blocked' site, it gives them a DNS error...that's not very friendly.

They have an addon app for custom block page, which allows you to display a simple message to the user (very basic html page) letting them know that it's blocked, instead of throwing a DNS error....BUT, their built in little page doesn't have an SSL certificate, so any HTTPS traffic that goes there needs to accept an unsigned certificate before they see the blocked page...which is just as bad as the dns error...my home users are not techy types....so, I thought to myself, self...how do I easily have a properly signed certificate....well, through NPM of course....so, I setup a proxy redirect with ssl, and then pointed my default page to that redirect, so any time someone hits my NPM without a proper name (like ANY blocked URL from my DNS server, NPM will redirect to the site I have defined and get the 'blocked' message I have setup.....except....http works, but https doesn't.....

So, do you have any suggestions on how to do the redirect that I'm trying to do?
...but within the settings there is an option to give it an alternate IP.

@ljlongwing commented on GitHub (Mar 21, 2023): Do you have suggestions for this scenario, which brought me here today? I am using Technitium DNS server and am using it primarily for DNS level add blocking. By default when a user on my home network tries to go to a 'blocked' site, it gives them a DNS error...that's not very friendly. They have an addon app for custom block page, which allows you to display a simple message to the user (very basic html page) letting them know that it's blocked, instead of throwing a DNS error....BUT, their built in little page doesn't have an SSL certificate, so any HTTPS traffic that goes there needs to accept an unsigned certificate before they see the blocked page...which is just as bad as the dns error...my home users are not techy types....so, I thought to myself, self...how do I easily have a properly signed certificate....well, through NPM of course....so, I setup a proxy redirect with ssl, and then pointed my default page to that redirect, so any time someone hits my NPM without a proper name (like ANY blocked URL from my DNS server, NPM will redirect to the site I have defined and get the 'blocked' message I have setup.....except....http works, but https doesn't..... So, do you have any suggestions on how to do the redirect that I'm trying to do? ...but within the settings there is an option to give it an alternate IP.

kerem commented

2026-02-26 06:33:23 +03:00

Author

Owner

@dnviti commented on GitHub (Oct 27, 2023):

This problem is still happening, our client in the Aerospace Industry is lowering our security class cause of that...
Would not be better to simply disable the default https host? Https on ip:443 is totally useless anyway.

@dnviti commented on GitHub (Oct 27, 2023): This problem is still happening, our client in the Aerospace Industry is lowering our security class cause of that... Would not be better to simply disable the default https host? Https on ip:443 is totally useless anyway.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#556

No description provided.

Rows
Columns