On 2023-01-10 13:43, Francis Daly wrote:

Using nginx (1.18.0 on Ubuntu 20.04.5) as proxy to back-end, I have three
sites (a|b|c.example.com) in a fast, reliable production environment. I have
DNS records set up for www.a|b|c.example.com.  I have CertBot set up for
only a|b|c.example.com.

To avoid "doubling" the number of sites-available and security scripts, and
to avoid the unnecessary "www." I would like to add something like:
/.../
There are 4 families of requests that the client can make:

* http://www.a.example.com
* http://a.example.com
* https://www.a.example.com
* https://a.example.com

It looks like you want each of the first three to be redirected to
the fourth?

Many thanks. That is totally correct. Given your comment re "lack of certificate" and "validation will fail" I have now expanded CertBot to include the three "www." names. All works fine (as far as I can see using Firefox, Opera, Vivaldi clients -- and Edge, had to boot up an old laptop!)

BUT... for that one step further and have all server (nginx) responses go back to the end-client as:
    https://a.example.com
and NOT as:
    https://www.a.example.com
            ^^^
I have written an /etc/nginx/conf.d/redirect.conf as:
server {
  server_name www.a.example.com;
  return 301 $scheme://a.example.com$request_uri;
}

which seems to work, but I would appreciate your opinion - is this the best, most elegant, secure way? Does it need "permanent" somewhere?

I've never used "scheme" before today, but we've got an external advisory audit going on, and I'm trying to keep them happy.

Many thanks and best regards,
Paul


It is straightforward to redirect the first two to the fourth --
something like

        server {
                server_name a.example.com www.a.example.com;
                return 301 https://a.example.com$request_uri;
        }

should cover both.

(Optionally with "listen 80;", it replaces your similar no-ssl server{}
block.)

But for the third family, the client will first try to validate the
certificate that it is given when it connects to www.a.example.com,
before it will make the http(s) request that you can reply to with
a redirect. And since you do not (appear to) have a certificate for
www.a.example.com, that validation will fail and there is nothing you
can do about it. (Other that get a certificate.)

Cheers,

        f

  \\\||//
   (@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:p...@stormy.ca _|____|____|
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx

Reply via email to