> > Just for testing purposes (if possible) you could either add the IP to
> > both listen directives or remove the ip part from the full-domain
> > server {} block to see if it changes anything.
>
> Hm. That doesn't really make sense to me.
>
> This server has multiple IPs. The hosted server needs to respond on a
> specific IP,
> so it needs the specific IP.
>
> The fallback is supposed to work for all "whenever it doesn't match" cases,
> so it
> doesn't get an IP, right?
Yes and no the 'default' fallback works for particular 'address:port' and
listen ip:443 seems to be different than just listen 443;
Out of personal interest I spun up an instance to replicate your setup and it
kind of confirms my suspicion:
If you have:
server {
listen 443 ssl http2;
ssl_certificate realdomain.crt;
ssl_certificate_key realdomain.key;
server_name realdomain;
return 403;
}
server {
listen 443 ssl http2 default;
ssl_certificate dummy.crt;
ssl_certificate_key dummy.key;
server_name _;
return 402;
}
Everything works as expected - you get first server for https://realdomain and
dummy cert for anything else.
The moment you change the first listen to listen real.ip:443 ssl http2; the
'default_server' doesn't work anymore and you always get the 'realdomain'
certificate (and also the test 403 response) for nondefined subdomain requests
and the order of server {} block
The workaround I found is then is to also define a dummy listen ip:port for the
catch server then the real certificate is not "leaked" in random requests:
server {
listen real.ip:443 ssl http2 default;
ssl_certificate dummy.crt;
.....
}
Unless there are (old) clients which don't support SNI (server name indication)
in general specifying the IP only on dns-level and using just 'listen 443 will
make the configuration more simple.
rr
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
