ssl_reject_handshake breaks other server blocks
Taco de Wolff
tacodewolff at gmail.com
Thu Feb 29 00:45:37 UTC 2024
Hi,
I've noticed at least in 1.24.0 and 1.25.4 that adding an
ssl_reject_handshake to the default server breaks SNI for other servers.
Example:
```
server {
server_name _;
listen 80 default_server;
listen 443 default_server ssl;
listen 443 default_server quic reuseport;
listen [::]:80 default_server;
listen [::]:443 default_server ssl;
listen [::]:443 default_server quic reuseport;
http2 on;
# SSL
ssl_certificate /etc/pki/lego/certificates/server.crt;
ssl_certificate_key /etc/pki/lego/certificates/server.key;
ssl_trusted_certificate /etc/pki/lego/certificates/server.crt;
ssl_reject_handshake on;
return 444;
}
server {
server_name domain.com;
listen 443 ssl;
listen 443 quic;
listen [::]:443 ssl;
listen [::]:443 quic;
http2 on;
root /srv/www/html;
# SSL
ssl_certificate /etc/pki/lego/certificates/server.crt;
ssl_certificate_key /etc/pki/lego/certificates/server.key;
ssl_trusted_certificate /etc/pki/lego/certificates/server.crt;
location / {
try_files /index.html =404;
}
}
```
There are two remarks for this example:
- While enabling HTTP/3 I had to add the ssl_certificate lines to the
default server, while using solely HTTP/2 this wasn't necessary. It will
throw an error on trying to start Nginx, is that a bug?
- The ssl_reject_handshake in the default server will prevent proper SNI
matching for domain.com. If I run `curl https://domain.com/` it works fine,
but `curl -k -H 'Host: domain.com' https://ipaddress-of-server/` does not.
When I remove ssl_reject_handshake it works as expected
My intent is to have a default server that responds to non-existing domain
names. Preferably it responds with 444, but requests over TLS (such as old
domains names with HTST) will throw a security warning that the server's
certificates don't match the request's virtual host's domain name (as
expected). Instead of showing a security warning in the browser I prefer a
connection error, which is why I want to employ ssl_reject_handshake.
Kind regards,
Taco de Wolff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20240228/01a77c9d/attachment.htm>
More information about the nginx
mailing list