On Fri, Jan 07, 2022 at 01:46:06PM -0500, David27 wrote:

Hi there,

> > If you have no "server_name www.thomas-walker-lynch.com;" (
>
> There is indeed a server block already defined with a server name
> www.thomas-walker-lynch.com.

"in a suitable server{}".

For a connection to port 80, there are 12 server{} blocks in your
config. They are irrelevant for a connection to port 443.

For a https connection to port 443, there are 2 server{} blocks.

One has one server_name: reasoningtechnology.com; and the other has
three server_names: thomas-walker-lynch.com, charset, and utf-8.

(The missing semi-colon is not a syntax error when the directive takes
any number of arguments; it's also not a problem that affects this
specific issue.)

None of those four are names or patterns that match
"www.thomas-walker-lynch.com".

> Nginx just chooses to use a different block
> that has a different server name. (Or perhaps I messed up the syntax for it
> lol) Note that everything else seems to be working.

Yes.

http://most-things should probably be working, because
they redirect to the expected https names; but I would expect that
https://anything-except-thomas-walker-lynch.com would give you the
content from the reasoningtechnology.com server.

(Because if you do not declare which server{} should be the
"default_server" for a particular IP:port when the request does not match
any server_name values, nginx knows that you intended its default choice
to be the one: http://nginx.org/r/listen)

> As for copying *everything* into the email ... 1) I thought folks would
> rather see the entire files rather than quotes from them, so I provided txt
> links. Did the link not work for you?

The entire files are good, yes. And the links worked for me yesterday.

They may or may not work for someone reading the mail archives in three
years, when they find they have a similar observed problem and they'd love
to know whether the specific problem-and-solution here applies to them.

> 2) Gosh I am also hesitant to put
> the entire sites .conf file in a public email list where for evermore they
> are viewable by people who might notice exploits, even those unrelated to
> the issue at hand.

That is a valid concern; best is if you can include a complete-but-minimal
config that shows the problem but shows no secrets. All of the unrelated
parts can be omitted, or replaced consistently with a different value.

The difficulty is that if you knew for certain which were the unrelated
parts, you probably wouldn't be asking the question.

I don't think there is a great resolution to that conflict, unfortunately.

> Well in any case, find the entire .conf file for the
> second virtual host below.

Thanks for making the config available.

In this case: for a https connection, only the server{} blocks with a
"listen 443"-type directive matter.

> server {
> server_name thomas-walker-lynch.com
> charset utf-8;
> listen [::]:443 ssl;
> listen 443 ssl;

> server {
> server_name reasoningtechnology.com;
> charset utf-8;
> listen [::]:443 ssl;
> listen 443 ssl;

There is no explicit "default_server", so "the first" is the default. If
they are part of nginx.conf because of an "include sites-enabled/*.conf"
directive, then the files are loaded in alphabetical filename order --
"c" before "t".

The fix is (probably) to change the server_name directive to include
all of the names that you want (https://nginx.org/r/server_name); being
aware that the client will likely be unhappy if it is presented with a
certificate that does not cover the name they used to access the service
-- so you might also want to change the certificate, if relevant.

Cheers,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx