Home / server / Questions / 1021041
In Process
Basil A
Asked: 2020-06-12 06:43:16 +0800 CST

Browsers reported SSL error when one of the server {..} blocks in NGINX configuration was removed

  • 772

After deleting a server {..} block from NGINX configuration and keeping two other server {..} block strange SSL errors starting showing up on the browsers:

  • Chrome reported the error ERR_SSL_PROTOCOL_ERROR

  • Firefox reported SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET

  • Curl reported gnutls_handshake() failed: An unexpected TLS packet was received

For some strange reason, these browser errors took place after removing one of the server {..} blocks and restarting NGINX. Running nginx -t before the restart showed a valid NGINX configuration with no problems. However, the restart introduced these problems.

I'm using Let's Encrypt certificates.

nginx -V

OUTPUT:
nginx version: nginx/1.14.0
built with OpenSSL 1.0.2g  1 Mar 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --add-module=/build/nginx-1.14.0/debian/modules/headers-more-nginx-module --add-module=/build/nginx-1.14.0/debian/modules/nginx-auth-pam --add-module=/build/nginx-1.14.0/debian/modules/nginx-cache-purge --add-module=/build/nginx-1.14.0/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-1.14.0/debian/modules/nginx-development-kit --add-module=/build/nginx-1.14.0/debian/modules/nginx-echo --add-module=/build/nginx-1.14.0/debian/modules/ngx-fancyindex --add-module=/build/nginx-1.14.0/debian/modules/nchan --add-module=/build/nginx-1.14.0/debian/modules/nginx-lua --add-module=/build/nginx-1.14.0/debian/modules/nginx-upload-progress --add-module=/build/nginx-1.14.0/debian/modules/nginx-upstream-fair --add-module=/build/nginx-1.14.0/debian/modules/ngx_http_substitutions_filter_module --add-module=/build/nginx-1.14.0/debian/modules/passenger/src/nginx_module
ssl nginx lets-encrypt

1 Answers

  1. After investigating this for so much time, the only thing that solved it was:

    1. Moving all the ssl_session_tickets off; outside the server {...} blocks in NGINX
    2. Add a single line inside the http {..} block of nginx with:
    http {
...
    ssl_session_tickets off;
...
}

    The answer here helped alot:

    ssl_session_tokens off breaks if it’s not set the same for all ssl-enabled server{} blocks. So if you have 2 server configurations and and you have ssl_server_tokens set to on in one (which is the default so it counts even if you omit it) and set to off in another, it will break the one where it’s set to off in certain browsers. The easiest way to resolve this, unless you have multiple http{} blocks, is to just set it to off in the http{} block. I have not tested to see if you you can have different settings in different http{} blocks as I haven’t had need to set up more than one http{} block.

    Although it might not be the exact same case, but the suggestion for moving ssl_session_tickets off; to the http {..} block and remove them from all server {..} blocks fixed the problem for me.

    • 2