On Sat, Jun 05, 2021 at 04:28:06AM -0400, forumacct wrote:
Hi there,
there are a few ways to approach this, depending on the end result that
you want.
I'll try to describe how things should work; maybe that will help you choose.
> Now I want to use certbot for https.
> But that requires certificates unique for each domain. (I think)
>
> So I tried deleting the default file and have two conf files in conf.d for
> each domain.
>
> vi /etc/nginx/conf.d/www.skywatcher.space.conf
> server {
> listen 80 default_server;
> listen [::]:80 default_server;
> root /media/usbstick/nginx/www;
> server_name skywatcher.space www.skywatcher.space;
> }
>
> vi /etc/nginx/conf.d/www.drgert.dyndns.ws.conf
> server {
> listen 80 default_server;
> listen 8000; # Alternate http port
> root /media/usbstick/nginx/www;
> # Add index.php to the list if you are using PHP
> index index.php index.html index.htm;
> server_name drgert.dyndns.ws www.drgert.dyndns.ws;
> location / {
> try_files $uri $uri/ =404;
> }
> # pass PHP scripts to FastCGI server
> location ~ \.php$ {
> include snippets/fastcgi-php.conf;
> fastcgi_pass unix:/run/php/php7.3-fpm.sock;
> }
> }
>
> But then each such file had 'default_server' keyword in it and it failed to
> work.
> Also I don't know if its OK that both try to listen on port 80.
For http, nginx sees a connection coming to an ip:port, and the request
has a Host: header value. Based on the server{}s that "listen" on that
ip:port, and the "server_name" values in those servers, nginx will choose
which one server{} to use to handle the request.
Each value has a default that is used if it is not explicitly set. And
if there is not a Host/server_name match, then the default_server for
this ip:port is used -- there must always be exactly one default_server
for each ip:port that nginx listens on.
(That is why the error was logged when you had two default_servers on
the same ip:port. If you care, you must tell nginx which one to use
as default. If you don't care, you can let nginx choose by not using
"default_server".)
So you can have two server{}s listening on the same ip:port, and nginx
will choose "the right" one based on your config and the request.
When you have only one server{}, most of that choosing does not matter --
nginx will always choose this server{}.
> So how do I do this right?
>
> Both domains pointing to the same html files root and both should receive
> https certificates. :-)
For https, most of the same applies, except before the request is made,
nginx must provide a certificate to the client to set up the encrypted
connection. And the *client* will probably care that that certificate
is valid for whatever name the client used to access nginx.
If you control the client, you can tell it what certificate to expect,
or you can tell it to accept any certificate at all. In that case, use any
certificate, and tell your client to accept it as valid. Generally, on the
public internet, you do not control the client, so this does not apply.
If you have two server_names that are used, and that will *always* serve
the same content as each other (and you are happy that someone who uses
one name will be able to see that the other name exists), then you can
get one certificate that is valid for both names, and configure nginx to
use that for all requests that are handled in this server{}. (The other
reply indicates that certbot does support this two-name certificate.)
If you want to keep the two server_names separate, then you will want
two certificates, one for each name; and you will want two server{}s,
each associated with one server_name and one certificate. And if they
both serve the same content today, you will need to duplicate the rest
of the config in the two server{}s. (You might be able to "include"
a common file, if you want to avoid writing things twice.)
In the main, nginx does not care what certificate you use; it is the
client that will decide whether the certificate presented by the server
is one that it will accept, and (generally) if the names do not match,
the client will default-fail and maybe invite the user to explicitly
accept things this time.
And whoever signs the certificate will want to be confident that you
control whatever their signing claims that you control -- for that, you
follow their recipe/requirements, or you find another signing authority.
So your choices are still: one server{}, one cert with both names; one
server{}, one cert with one name, and let users that access the other
name choose whether or not to continue; or two server{]s, each with a
cert with one name.
Hopefully the above describes why those are the choices; and gives an
idea of the costs/benefits of each, so that you can choose which is most
appropriate for your system.
Cheers,
f
--
Francis Daly fran...@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
