Nginx Nginx Config... I think I made a big mistake!

It was brought to my attention today that my site is being served at multiple URLs (horrifying, as this is something I thought I had protected against). I suspect the problem began when I moved my site to SSL last year. Now, my site (the only site configured on my server at port 443) is being delivered via HTTPS via all of the domains which point to my server (and yes... Chrome does throw a domain/certificate mis-match warning when you attempt to access them).

Basically, my site should only be served at https://www.example.net. Any other requests should be redirected to that domain via 301 redirect, so https://example.net and the non-HTTPS variants like http://www.example.net and http://example.net should all 301 to the official domain.

I also own example.com, which many people mistakenly type in, so these redirects need to work as well to send visitors to example.net.

When making my initial configuration, I had not considered what happens if you access the above domains with the HTTPS protocol. So, if you access http://example.com or http://www.example.com or http://example.net, they all redirect exactly as they should. However, if you access any of those domains via https://, there is no redirect and the entire site is accessible on the domain.

Here's my current Nginx server configurations:

Code (Text):

# REDIRECT OTHER DOMAINS
server {
   listen   80;
   server_name   example.net www.example.net example.com www.example.com;
   return   301 https://www.example.net$request_uri;
}

# PRIMARY SITE CONFIG
server {
   listen   443 ssl http2;
   server_name   www.example.net;
   ...
}

After reviewing the Nginx documentation again, I think I know what is happening now: all the HTTPS requests coming in over port 443 are, per Nginx default rules, being served by the second server block, because it is the only one configured to listen on that port. I had been under the impression that it would only serve content if the request matched the server_name, but clearly that was wrong.

Now I am left with a few questions on how to fix this mess. First: is it possible to configure HTTPS redirects without having SSL certificates for each of the domains? In other words, can I redirect https://www.example.com to https://www.example.net without buying another SSL certificate for example.com?

I presume the answer to that question is "no", which leads me to the question about what to do next. What is the best practice for handling this situation?

Should I create another server block to act as the default server for requests on 443 which returns the Nginx non-standard 444 HTTP error code (it's explained in the docs here)? That would give me something like this:

Code (Text):

# REDIRECT OTHER DOMAINS
server {
   listen   80;
   server_name   example.net www.example.net example.com www.example.com;
   return   301 https://www.example.net$request_uri;
}

# HTTPS DEFAULT SERVER
server {
   listen   443 ssl http2;
   server_name   example.com www.example.com;
   return   444;
}

# PRIMARY SITE CONFIG
server {
   listen   443 ssl http2;
   server_name   www.example.net;
   ...
}

---

I'm not sure how to handle this. Any advice would be appreciated!

 

Thanks for your help, @eva2000! After thinking it over and doing more analysis, I think I just want to send all the other domains to a dead end when someone tries to access them via https://. I doubt any normal person would type out the "https" if they try to visit my website, and I don't think there are any important backlinks to the incorrect domains out there. I really just want to get the duplicate content removed from Google, and to ensure this cannot happen again.

Would something like this be the best way to achieve that?

Code (Text):

# REDIRECT OTHER DOMAINS
server {
  listen   80;
   server_name   example.net www.example.net example.com www.example.com;
   return   301 https://www.example.net$request_uri;
}

# TERMINATE ALL INCORRECT HTTPS REQUESTS
server {
   listen   443 ssl http2;
   server_name   example.net example.com www.example.com;
   return   404;
}

# PRIMARY SITE CONFIG
server {
   listen   443 ssl http2;
   server_name   www.example.net;
   ...
}

*** EDIT/UPDATE ***

Nothing seems to be working, including this above — it's catching all of the normal requests to my site and makes it return 404s as well.

I just want to deny all 443/ssl/https requests which are not to www.example.net by default; that's it.

Yeah, I suspect that many people might have this problem without realizing it. I probably just noticed it because I run a ".net" website with ".com" redirects.

 

OK, so this is a much more complicated issue than I originally thought. Apparently, configuring "default" behavior for Nginx sites using SSL is quite different from that of non-SSL sites.

I see three practical options:

Option 1: Create a self-signed certificate and use it to handle unwanted SSL requests. This is explained in more detail here: Nginx: rejecting unknown or specific domains over SSL

Option 2: Use an "if" conditional in the appropriate server block to check to see if the $host variable from the request matches the defined $server_name. This is suggested and explained in the following answer on StackOverflow: ssl - Properly setting up a "default" nginx server for https - Server Fault

Option 3: Host the SSL site on a dedicated IP address that is not used for any other domains.

I have decided to proceed with Option #2, and it is working as expected. I do have some performance concerns about using an "if" conditional statement in my server block, but these are probably overblown (I hope), and it is the fastest/easiest option for me to implement and maintain, which is worth a lot.

If any of you have any concerns about using "if" in my server block this way, please let me know. My Nginx configuration for the SSL site looks something like this now:

Code (Text):

server {
   listen   443 ssl http2;
   server_name   www.example.net;
   
   if ($host != $server_name)
   {
      return 444;
   }
   
   ...
}

I have also decided to offload the non-SSL redirects from other domain names to my domain registrar, NameSilo. They offer path forwarding, so they will be handling all of my example.com and example.com/whatever-path redirects now, while blocking https requests, and I won't have those old rules cluttering up my Nginx config files.

 

Yeah, for sure. In my case, though, I only want to serve everything exclusively, from one domain, via SSL.

Surprisingly, that proved to be the more difficult configuration!

 

Wow, that's great. Very cool!