Score:2

Should there be an explicit catch-all NGINX `server` block to dismiss HTTPS requests for the domains **not** served by the server?

sy flag

The most common NGINX config I see is the one below, where it is made sure that all relevant HTTP requests are redirected and the irrelevant ones are dismissed, but usually I only see one server block to handle HTTPS, which is mostly also the implicit default server for all HTTPS requests, regardless of what the Host header says. (Reminder to self.)

I just learned that, for whatever reason, domain names can get resolved to the wrong IP address, therefore requests can hit the wrong servers (e.g., 1, 2, 3). According to the HTTPS specification (RFC 2818, "HTTPS Over TLS")1, the requested domain must be checked with the domain in the server's certificate (section 3. Endpoint Identification), so the problem of irrelevant requests should take care of itself.

The only reason I can think of in favor of an HTTPS catch-all clause for irrelevant requests is to safeguard against clients with an improper HTTPS implementation (which is always a safe bet).

[1]: At the top of RFC 2818, it says that it is "Obsoleted by: 9110". Went there for updates, but the only references to this topic I could find was in section 1.4. Specifications Obsoleted by This Document that redirects to section B.1. Changes from RFC 2818 in Appendix B. Changes from Previous RFCs which simply states: "None"...

##################
# HTTP catch-all #
##################
server {
   listen      80 default_server;
   listen [::]:80 default_server;

   server_name _;

   return 404;
}

########################## ( see other flavors:
# HTTP-to-HTTPS redirect #   https://serverfault.com/questions/1141066
########################## )
server {
    listen      80;
    listen [::]:80;

    server_name ourdomain.com;

    return 301 https://ourdomain.com$request_uri;
}

#########
# HTTPS #
#########
server {
    listen 443 default_server ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;

    # ... rest of the instructions ...
}

edit (2023-08-26):

The catch-all block I'm currently using is from the Stackoverflow thread Catch-all nginx server blocks for invalid subdomains:

#############################
# CATCH-ALL (https & https) #
#############################
                                            
server {                                    
    listen      80  default_server;          
    listen [::]:80  default_server;          
    listen      443 default_server ssl;     
    listen [::]:443 default_server ssl;     
                                            
    ssl_certificate     /some/path/any.crt; 
    ssl_certificate_key /some/path/any.key; 
                                                      
    return 444;
    # silently drop the connection
    # ... or you can define some 
    # landing page here instead
}

The self-signed dummy certificate and private key is generated via

openssl req -nodes -new -x509 -subj "/CN=localhost" \
  -keyout /some/path/any.key \
  -out    /some/path/any.crt
Score:3
jp flag

Yes.

It's better if the third server block is not a "default server" as the client's browser will otherwise generate a warning as the server's certificate does not match the requested domain.

You can add a listen 443 ssl default_server; to the first server block - you will need to provide an ssl_certificate and ssl_certificate_key

You could reuse the credentials from another site. The client's browser will still generate a warning (that cannot be avoided), but if the user clicks through anyway, they will get the return code instead of your website.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.