Nginx ssl_protocol setting doesn't work

Question

I'm trying to change the settings for Nginx ssl_protocols, but the changes don't reflect on the server.

At first I thought it was because we were using Ubuntu 12.04, but now we're updated to 14.04.

Nginx version:

nginx version: nginx/1.10.1
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
built with OpenSSL 1.0.1f 6 Jan 2014
TLS SNI support enabled
configure arguments: --sbin-path=/usr/local/sbin/nginx --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module

Openssl version:

OpenSSL 1.0.1f 6 Jan 2014

Ngnix.conf:

http {
    include       /usr/local/nginx/conf/mime.types;
    default_type  application/octet-stream;

    tcp_nopush     on;
    keepalive_timeout  65;
    tcp_nodelay        off;

    log_format  main  '$remote_addr - $remote_user [$time_local] $status '
                      '"$request" $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    error_log   /var/log/nginx/error.log   debug;

    open_file_cache           max=1000 inactive=20s;
    open_file_cache_valid     30s;
    open_file_cache_min_uses  2;
    open_file_cache_errors    on;
    client_body_timeout   10;
    client_header_timeout 10;

    sendfile        on;

    # output compression
    gzip on;
    gzip_min_length  1100;
    gzip_buffers     4 8k;
    gzip_proxied     any;
    gzip_types       text/plain text/html text/css text/js application/x-javascript application/javascript application/json;

    # include config for each site here
    include /etc/nginx/sites/*;

/etc/nginx/sites/site.conf:

server {
  listen 443 ssl;
  server_name server_name;
  root /home/deploy/server_name/current/public;
  access_log  /var/log/nginx/server_name.access.log  main;

  ssl_certificate         /usr/local/nginx/conf/ssl/wildcard.server_name.com.crt;
  ssl_certificate_key     /usr/local/nginx/conf/ssl/wildcard.server_name.com.key.unsecure;
  ssl_client_certificate  /usr/local/nginx/conf/ssl/geotrust.crt;

  ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

  ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA;
  ssl_prefer_server_ciphers on;

  location ~ ^/assets/ {
    expires max;
    add_header Cache-Control public;
    add_header ETag "";
    break;
  }

  location / {
    try_files $uri @server_name;
    proxy_set_header   X-Forwarded-Proto https;
  }

  location @server_name {
    include proxy.conf;
    proxy_pass http://server_name;
    proxy_set_header   X-Forwarded-Proto https;
  }

  # stats url
  location /nginx_stats {
    stub_status on;
    access_log   off;
  }

}

The config files get loaded properly and are both being used as intended. If it has any relevance the server is running Ruby on Rails with Unicorn.

Does anyone have an idea what could be wrong?

Answer 1

Want to add another (somewhat obscure) possibility since the CERTbot one didn't cover me. Mine is only for NGINX installs with multiple domains. Basically the info you specify for your specific domain may be modified because of the server default. That default is set from the first domain name encountered when reading the config (basically alphabetically). Details on this page.

http://nginx.org/en/docs/http/configuring_https_servers.html

A common issue arises when configuring two or more HTTPS servers listening on a single IP address:

server {
    listen          443 ssl;
    server_name     www.example.com;
    ssl_certificate www.example.com.crt;
    ...
}

server {
    listen          443 ssl;
    server_name     www.example.org;
    ssl_certificate www.example.org.crt;
    ...
}
With this configuration a browser receives the default server’s certificate, i.e. www.example.com regardless of the requested server name. This is caused by SSL protocol behaviour. The SSL connection is established before the browser sends an HTTP request and nginx does not know the name of the requested server. Therefore, it may only offer the default server’s certificate.

Answer 2

Description

I had a similar problem. My changes would be applied (nginx -t would warn about duplicate and invalid values), but TLSv1.0 and TLSv1.1 would still be accepted. My line in my sites-enabled/ file reads

ssl_protocols TLSv1.2 TLSv1.3;.

I ran grep -R 'protocol' /etc/nginx/* to find other mentions ssl_protocols, but I only found the main configuration file /etc/nginx/nginx.conf and my own site config.

 

Underlying problem

The problem was caused by a file included by certbot/letsencrypt, at /etc/letsencrypt/options-ssl-nginx.conf. In certbot 0.31.0 (certbot --version) the file includes this line:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

This somewhat sneakily enabled these versions of TLS. I was tipped off by Libre Software. 0.31.0 is the most up-to-date version I was able to get for Ubuntu 18.04 LTS

 

Solution

TLS versions <1.2 were disabled by default in the certbot nginx config starting from certbot v0.37.0 (thank you mnordhoff). I copied the file from there into the letsencrypt config (options-ssl-nginx.conf), added a note to myself and subsequent maintainers and everything was all right with the world again.

 

How to not get into this mess in the first place

grepping one level higher (/etc/* instead of /etc/nginx*) would have allowed me to find the culprit. But a more reliable and powerful tool is nginx -T, which prints out all the configuration files that are considered. Other useful commands:

• nginx -s reload after you change configs
• nginx -v to find out your nginx version. To enable TSL version 1.3, you need version 1.13.0+.
• openssl version: you need at least OpenSSL 1.1.1 "built with TLSv1.3 support"
• curl -I -v --tlsv<major.minor> <your_site> for testing whether a certain version of TLS is in fact enabled
• journalctl -u nginx --since "10 minutes ago" to make absolutely sure something else isn't going on.

Answer 3

The issue wasn't in the server itself, but instead in the AWS Load Balancer having wrong SSL Ciphers selected.