> > 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
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx