Fallback default server sharing cert information about other domains than for the URL you visit ?
Reinis Rozitis
r at roze.lv
Fri Aug 9 18:14:05 UTC 2019
> > 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
More information about the nginx
mailing list