0

I am using NGINX for 301 redirects on Ubuntu and reverse proxy for my Web Application and aim is to redirect traffic to non-www url such as https://mywebapplication.example.

So with my current config for NGINX Conf File:

mywebapplication.example -> https://mywebapplication.example
www.mywebapplication.example -> https://mywebapplication.example
http://mywebapplication.example -> https://mywebapplication.example
http://www.mywebapplication.example -> https://mywebapplication.example
192.0.2.123 -> https://mywebapplication.example
http://192.0.2.123 -> https://mywebapplication.example

Works fine but when IP with HTTPS is provided in the URL, I get "Your connection is not private."

https://192.0.2.123 -> Your connection is not private

Here's my NGINX Conf.

server {
    listen 192.0.2.123:80;

    location / {
        proxy_pass "http://localhost:4000/";
        proxy_http_version 1.1;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
    }
}

server {
    listen 192.0.2.123:80;
    server_name  192.0.2.123 192.0.2.123:4000;
    return       301 https://mywebapplication.example$request_uri;
}

server {
    listen 80 http2;
    listen [::]:80 http2;
    server_name  mywebapplication.example www.mywebapplication.example;
    return       301 https://mywebapplication.example$request_uri;
}

server {
    listen       443 ssl http2;
    server_name  www.mywebapplication.example;
    return       301 https://mywebapplication.example$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name mywebapplication.example;
    ...
    ...
    ...
    ...
}

How can I handle IP with HTTPS to a successful 301 redirection?

https://192.0.2.123 -> https://mywebapplication.example

  • 1
    1) Please do not badly obfuscate, 123.456.789.123 is certainly not an IPv4 address. I edited your post using appropriate values. 2) you get the error because there is no X509 certificate provided for the given IP address, which is "normal" in the sense that while technically possible, certificates are used for names, not addresses in the HTTPS world. Instead of trying to do that, just configure your webserver to not reply when the SNI/Host information is absent (or live with the error message, noone should enter such URLs with IPs anyway). – Patrick Mevzek Oct 18 '18 at 21:01
  • @DynamicRemo This might be best asked over on Server Fault where they have more experience with Nginx configurations, but it looks like you got an answer in the above comment. If you like, I can still migrate it there however. – dan Oct 19 '18 at 4:45
  • Thank you @PatrickMevzek. One concern for me is that Google has somehow crawled my site with Https version of IP, so when a user clicks/navigates with that URL this problem persists. Any solution to this particular scenario? Thanking You! and thanks @dan, I saw the migration you made. – Dynamic Remo Oct 19 '18 at 14:19
1

I would very strongly recommend not worrying about redirecting HTTPS access by IP address. It is a very rare setup that reduces a lot of your hosting flexibility for very little benefit. Chances are that none of your users will access your site by IP, and if they do for some reason out of curiosity, they will expect the behavior to be undefined.

The top internet companies such as Google, Facebook, and Reddit all give certificate errors for IP access by HTTPS - so if they aren't worrying about it, neither should you.

If you decide that you absolutely, definitely need to redirect from HTTPS accessed by IP address (which again, I strongly suggest you do not worry about), you will need to purchase an HTTPS certificate that includes the IP address in both the CN and SAN fields. This is a rare setup for public-facing websites, and many certificate authorities (including Let's Encrypt) do not support it.

Lastly, I would not worry too much about Google indexing your IP address in Google search. If you want to ensure 100% that it doesn't happen, the simple fix is to include a meta canonical tag on each one of your web pages with the page's preferred URL, or alternatively you can verify your website in Google Search Console.

  • P.S. If you are curious and want to see one of the rare exceptions of a public-facing HTTPS IP address cert, check out the website for CloudFlare's DNS service (with IP cert issued by DigiCert): 1.1.1.1 – Maximillian Laumeister Oct 19 '18 at 21:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.