Nginx ssl_protocol设置不起作用

时间:2016-06-10 15:26:16

标签: ruby-on-rails ubuntu ssl nginx

我正在尝试更改Nginx ssl_protocols的设置,但更改并未反映在服务器上。

起初我以为是因为我们使用的是Ubuntu 12.04,但现在我们已经更新到了14.04。

Nginx版本:

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版本:

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;
  }

}

配置文件正确加载并且都按预期使用。如果它有任何相关性,服务器正在使用Unicorn运行Ruby on Rails。

有没有人知道可能出现什么问题?

3 个答案:

答案 0 :(得分:1)

想添加另一种(有点晦涩)的可能性,因为CERTbot没有覆盖我。 Mine仅适用于具有多个域的NGINX安装。基本上,由于服务器默认设置,您为特定域指定的信息可能会被修改。该默认值是从读取配置时遇到的第一个域名(基本按字母顺序)设置的。此页面上的详细信息。

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.

答案 1 :(得分:0)

问题不在服务器本身,而是在AWS Load Balancer中选择了错误的SSL密码。

答案 2 :(得分:0)

说明

我有类似的问题。我的更改将被应用(nginx -t会警告重复和无效的值),但是TLSv1.0和TLSv1.1仍将被接受。我的启用了网站的文件中的行显示为

ssl_protocols TLSv1.2 TLSv1.3;

我运行grep -R 'protocol' /etc/nginx/*来查找其他提及的ssl_protocols,但我只找到了主配置文件/etc/nginx/nginx.conf和我自己的站点配置。

基本问题

该问题是由于certbot / letsencrypt包含的文件位于/etc/letsencrypt/options-ssl-nginx.conf。在certbot 0.31.0certbot --version)中,文件包含以下行:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

这有点偷偷启用了这些版本的TLS。 Libre Software告诉了我。 0.31.0是我能够为Ubuntu 18.04 LTS获得的最新版本

解决方案

默认情况下,从certbot v0.37.0开始,certbot nginx配置中禁用了<1.2版的TLS版本(感谢mnordhoff)。我从那里将文件复制到letencrypt配置(options-ssl-nginx.conf)中,给自己和后来的维护者添加了一条便条,一切都恢复了。

如何一开始就不陷入困境

提高一级(/ etc / *而不是/ etc / nginx *)可以让我找到罪魁祸首。但是nginx -T是更可靠,功能更强大的工具,它可以打印出所考虑的所有配置文件。 其他有用的命令:

  • nginx -s reload更改配置后
  • nginx -v来查找您的nginx版本。要启用TSL版本1.3,您需要version 1.13.0+
  • openssl version:您至少需要OpenSSL 1.1.1 "built with TLSv1.3 support"
  • curl -I -v --tlsv<major.minor> <your_site>用于测试是否确实启用了特定版本的TLS
  • journalctl -u nginx --since "10 minutes ago",以确保没有其他事情发生。