Fallback default server sharing cert information about other domains than for the URL you visit ?

[Reinis Rozitis]

> I expect it to fail with a 444, and only have info about the failed subdomain.

The SSL handshake happens before the http status and since the browser doesn't get a valid certificate it immediately throws an error and ignores the rest.
Unless the users override the error on the browser side (iirc with HSTS it's not even possible as with invalid or expired certs) you can't expect that they will get the return code.


> Why does it respond with cert info about the "example.com, www.example.com
> " certs at all?  Those are only for the full-domain site.

I might be wrong (needs a clarification from nginx dev/support people) but if the configuration is as you have included in the email it might be that the default_server directive doesn't work as expected since you have different listen blocks:

listen 172.17.0.1:443 ssl http2;
vs
listen 443      ssl http2 default_server;

Since nginx can have a different default_server for different 'address:port' pairs depending on what 'listen 443' is actually expanded to (just a guess 0.0.0.0:443) it could be that the nginx decides that it has to use the certificates from first server {} (in the order in configuration) rather than the catch all fallback. 

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.


Other than that depending on the requirements the other options are just to make a matching server block with a valid certificate (with Lets Encrypt it's quite simple and free) or have an *.example.com wildcard SSL so the browsers are satisfied with whateversubdomain.example.com.

rr