Changes for page How to setup an Nginx reverse proxy and also provide a global X.509 certificate for it

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -136,7 +136,7 @@
136	136	Well, yes, this is an issue. But that's why there's more to show you, in the next section!
137	137
138	138
139		-= Setting up HTTP->HTTPS automatic redirecting and configuring a global X.509 certificate =
	139	+= Setting up HTTP->HTTPS automatic redirecting =
140	140
141	141	Time to get into the groove of things!
142	142	First, we shall create a new configuration file in "/etc/nginx/sites-available" and then a symbolic link towards it in "/etc/nginx/sites-enabled" called "fallback.conf". Why?
...	...	@@ -145,4 +145,80 @@
145	145
146	146	The contents of this "fallback.conf" file are as follows:
147	147
	148	+{{code language="nginx"}}
	149	+server {
	150	+ listen [::]:443 ssl http2 default_server; # managed by Cert
	151	+ listen 443 default_server;
	152	+ server_name _;
	153	+ include /etc/nginx/snippets/ssl.conf;
	154	+ return 404;
	155	+}
148	148
	157	+server {
	158	+ server_name pentilescu.com;
	159	+ return 301 https://alexandru.pentilescu.com$request_uri;
	160	+
	161	+ listen 80;
	162	+ listen [::]:80;
	163	+ listen 443 ssl;
	164	+ listen [::]:443;
	165	+}
	166	+
	167	+server {
	168	+ server_name _;
	169	+ return 301 https://$host$request_uri; # managed by Certbot
	170	+
	171	+
	172	+ # return 301 https://$host$request_uri;
	173	+
	174	+ listen 80 default_server;
	175	+ listen [::]:80 default_server;
	176	+ listen 443 ssl;
	177	+ listen [::]:443;
	178	+}
	179	+{{/code}}
	180	+
	181	+Each of these 3 server blocks have a well defined purpose. Let's break them down!
	182	+
	183	+The most important thing to remember is how Nginx does request matching.
	184	+
	185	+To put it simply, you can have as many ".conf" files in the "sites-enabled" directory as you wish to have. And any one ".conf" file can contain multiple "server" directives, each with its own proxy_pass destination and with its own subdomain service name.
	186	+
	187	+So, when a new HTTP/HTTPS request arrives at our Nginx server, how does it decide which "server" directive to match with that specific request, so that it knows where to redirect it to?
	188	+
	189	+The answer is fairly easy: for each request, Nginx looks through all of the ".conf" files under "sites-enabled", looks through each ".conf" file's "server" directives while taking into account its "server_name" and "listen" directives and then it decides to match those which are the most specific to our request's parameters.
	190	+
	191	+To put it as simply as possible, suppose the aforementioned bitwarden.conf file is created and there's also the fallback.conf file as with the previous contents, as well.
	192	+
	193	+When a new request arrives to our server, destined to passwords.pentilescu.com port 443, our server will look at both of these ".conf" files. Let's suppose it starts looking with the fallback.conf file.
	194	+It sees 3 "server" blocks in fallback.conf, the first of which matches for any incoming connections for port 443 (which matches our request) and matches for literally any server name (that's what the "_" after the "server" directive means). Since it matches for any server name, this is not a very specific match. Nginx will remember this as the closest match it has for now and then continue to look for other "server" blocks as well.
	195	+
	196	+The second "server" block only matches for requests directed at "pentilescu.com", not for any of its subdomains. As the request was made specifically to passwords.pentilescu.com, which is a subdomain of pentilescu.com, this does not match with this block at all. Nginx continues.
	197	+
	198	+The third "server" block matches with the server_name directive (as the server name is the "_" wildcard once again), and it also matches with the ports (both port 80 and 443 this time). Nginx will also remember this one as a viable candidate for resolving the request.
	199	+
	200	+Then, Nginx will also take a look at the bitwarden.conf file.
	201	+
	202	+Here, there is one single "server" block, one which matches exactly with the "passwords.pentilescu.com" server name (as well as the 443 port). As this one has an exact match to both server_name and port, this is the most specific one to match.
	203	+
	204	+As such, Nginx will resolve to use that server block for this request and redirect it to that server's port. As such, the configuration from bitwarden.conf won over the configurations in fallback.conf.
	205	+
	206	+Simple, right?
	207	+
	208	+Now, you might wonder, what's the purpose of the first server block in fallback.conf, then. Well, fallback.conf should contain, ideally, resolution requests for stuff that doesn't match anything that's specific.
	209	+
	210	+For example, suppose the aforementioned setup, but with a request for "abcdefg.pentilescu.com" port 443. Where should such a request go to?
	211	+
	212	+Well, it doesn't match the "passwords.pentilescu.com" server_name block in bitwarden.conf. Nor does it match the "pentilescu.com" server block either, as it's a subdomain for pentilescu.com. The only two matching candidates, as such, are the first and third "server" blocks in fallback.conf, which resolve to any name whatsoever, due to their wildcard server_names. In this situation, Nginx will just take the first one, just because that's the one to contain the "default server" descriptor for port 443 (i.e. it should handle anything that comes to port 443 and doesn't have a more specific match) and uses that one. The action detailed for this "server" block is "return 404", which tells Nginx to simply return a 404 status code, immediately. The browser will then report this "404" status code to the visitor, letting him know that the service he/she was attempting to access does not exist on this server, an indication that their request was malformed.
	213	+
	214	+This block effectively handles all malformed requests or any request that does not have a specific resolver for it.
	215	+
	216	+The second "server" block in fallback.conf is specifically for all requests coming to "pentilescu.com", not any of its subdomains. It listens to both ports 80 and 443 and, when it matches, it will return an HTTP code 301 to "https://alexandru.pentilescu.com$request_uri", effectively preserving the exact same URI that was used in the original request but simply redirecting it forcefully to the "alexandru.pentilescu,com", so that any requests to "pentilescu.com" will redirect the browser to "alexandru.pentilescu.com". Basically, this is a forced redirection so that, when accessing the naked domain, one would forcefully be redirected to a specific subdomain. This is just a quirck of my own website. You may choose not to include this behavior in your own platform.
	217	+
	218	+Finally, the third and last "server" block in our fallback.conf matches to literally any server name due to its wildcard and is the default server for port 80. Being the default server, this means this block will handle all requests coming from port 80 to our server that doesn't have a match. The action of this block is to return a 301 HTTP code to "https://$host$request_uri". "https://$host$request_uri" will resolve to the exact same URL as the original requested one, except that it has the "https://" prefix before it, instead. This means that we're telling Nginx that, for any request that doesn't have a better match to it coming from port 80 (i.e. through the HTTP protocol) we must send back a HTTP response code of 301 (i.e. redirect to) to redirect our visitor to the exact same URL that they already used but with the "https://" prefix appended, effectively forcing them to use port 443 instead. This will move all their requests from HTTP to HTTPS to automatically secure them with encryption!
	219	+
	220	+And, moreover, if we don't add any more "server" directives in any other one of our ".conf" files for Nginx, this block will always be used for incoming port 80 requests, so that nothing more specific resolves for them and we can handle all of them by redirecting them to use a more secure protocol.
	221	+
	222	+Pretty cool, right?
	223	+
	224	+Finally, let's see how we can configure an X509 certificate globally!