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
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx
