#1169 closed defect (wontfix)
TLS works without supplying the ssl parameter without a WARN
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | other | Version: | 1.11.x |
| Keywords: | Cc: | ||
| uname -a: |
Linux c0rn3jRPi3B 4.4.39-1-ARCH #1 SMP Sun Dec 18 18:25:13 MST 2016 armv7l GNU/Linux |
||
| nginx -V: |
nginx version: nginx/1.11.8
built with OpenSSL 1.0.2j 26 Sep 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --user=http --group=http --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-pcre-jit --with-file-aio --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --with-stream_ssl_preread_module --with-stream_geoip_module --with-stream_realip_module |
||
Description
If there is a server block for the same port/IP that already has the ssl parameter enabled, it doesn't need to be enabled in other server blocks and it works, without throwing an error or a warning when starting up/checking the config with -t.
The correct behavior in my opinion would be warning the user about the fact, as they can make the server blocks dependent on other server blocks.
server { # < ---- this works fine but it doesn't throw a warning
listen 443 http2;
listen [::]:443 http2;
server_name c0rn3j.com;
...
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name wiki.c0rn3j.com;
...
}
➜ ~ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Change History (4)
comment:1 by , 8 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 8 years ago
Logging a warning wouldn't break backwards compatibility, and would alert users to a confusing, brittle and possibly erroneous configuration. While annoying everyone who does it on purpose, of course.
comment:3 by , 8 years ago
Annoying people who use this on purpose could be solved by setting some flag in the config file perhaps?
comment:4 by , 8 years ago
There can be a lot of listening options, and requiring users to specify them all in all the listen directives in the configuration is certainly counter-productive.
This behaviour is intentional. Listening sockets can be shared between multiple server{} blocks (see How nginx processes a request), and the
sslparameter can be either used in all listen directives to make it more obvious in the configuration that the socket in question is using SSL, e.g.:server { listen 443 ssl; ... } server { listen 443 ssl; ... } server { listen 443 ssl; ... }or not used at all in non-default servers, e.g.:
server { listen 443 ssl; ... } server { listen 443; ... } server { listen 443; ... }We certainly don't want to break configurations using either of these approaches.