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