Hi,

> you can't expect that they will get the return code.

Okay I guess that makes sense.

Is there any other way to get an attempt to connect to a un-hosted site to get a "nobody home, go away" response?
Something other than the current "there's a problem with the cert" mis-message?

> I might be wrong (needs a clarification from nginx dev/support people)

No worry. Hope somebody that's sure will chime in eventually.

> 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?

Did I misunderstand your point?

> 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


A subdomain wildcard like that assumes that ALL subdomains of example.com are unhosted. That's not true here.

There are an infinite number of possible mismatches. I can't really set up a "valid cert" for each one.

This is about the fallback. I thought that's what the fallback is supposed to handle.

Let's see if a 'dev' has some other comments.

Thanks!
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx