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

koocr at mailc.net koocr at mailc.net
Fri Aug 9 17:27:38 UTC 2019


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


More information about the nginx mailing list