If you look at my post above ("I had a site with this configuration"), you will see the set up I had. This was the first ssl site, and the second site defined. It was defined in nginx.conf, above the
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
lines of nginx.conf. I intended to tell visitors who arrived by IP or DNS error, that the site they wanted was not on this server.
With the server present,
all ssl sites (except that one) failed with a protocol error.
The default site worked if warning about self signing were ignored.
With the server absent all ssl sites worked fine.
Note - all the other ssl sites have their own certificates and keys, so will not have picked up the self-signed certificate.
I suspect this was introduced in nginx 1.21.6 or openSSL 1.1.1.n. I'm using nchan so can't use later versions, pending a bug fix.
@Osiris - It is indeed default behaviour to resort to a default vhost, but that is not what was happening. I think the server was sending a reply the browser took as a protocol error. I don't know which made the error.
It is really exasperating that ssl cannot be tested, except on live sites. Makes testing so difficult
No, that section deals with non-SNI clients. Modern browsers are all SNI capable. See the section just below that for how SNI works. And, I meant there are no docs that deal explicitly with the inheritance rule for missing ssl_certificate lines. I am not surprised as that should never be in normal use but comes up in debugging or clever new setups.
Even with non-SNI that doc shows which server block is selected - which would be the default one (or first if no explicit default specified). That would still be a functional server block and the reason for your protocol violation remains a mystery.
You have a somewhat unusual setup (your own binary, nchan) and an unusual failure. I am glad you found a work-around. If it is a bug in a later nginx handling self-signed certs it would be a serious regression as using a self-signed cert has many valid uses. (I am on 1.20)
UPDATE: I saw your sample config but it only had the includes not the contents of those. A better debugging method is to use nginx -T to see everything. But, I don't think it's worth pursuing your unusual symptom now you have something working.
I guess I was not clear. In my testing and experience, if you have any "listen 443 ssl" directives paired with a self signed certificate, then yes indeed, visitors can accept the warning, and visit that site. BUT..
