SSL, Django, Gunicorn, NGINX - сайт не может быть достигнут, используя https:// + domain.com

Я недавно запустил сайт, который использует SSL, в частности Comodo PositiveSSL.

У меня только проблема в том, что я не могу зайти на сайт используя

https://example.com

Я настроил перенаправления в NGINX для http. Вот мой конфиг:

upstream myapp {
    server localhost:8000;
}

server {
    listen 80;
    server_name www.example.com example.com;
    root /var/www/;
    if ($host !~* ^(example.com|www.example.com)$ ) {
        return 444;
    }
    return 301 https://$host$request_uri;
}

server {
    listen 443 default ssl;
    root /var/www/;
    server_name www.example.com example.com;
    if ($host !~* ^(example.com|www.example.com)$ ) {
      return 444;
    }

    ssl_certificate      /etc/nginx/ssl/my_crt.crt;
    ssl_certificate_key  /etc/nginx/ssl/my_crt.key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;

    access_log /var/log/nginx/myapp_access.log;
    error_log /var/log/nginx/myapp_error.log;
    gzip on;
    gzip_http_version 1.0;
    gzip_proxied any;
    gzip_types text/css application/x-javascript;
    gzip_vary on;
    client_max_body_size 0;
    try_files $uri @myapp;

    location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 365d;
    }

    location @myapp {
        client_max_body_size 0;
        proxy_pass http://domain;
        proxy_redirect off;
        proxy_read_timeout 5m;
        proxy_set_header Host            $host;
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Мой DNS-регистратор - namecheap, и у меня также есть перенаправление URL в моей cpanel:

host: @
value: http://www.example.com

Благодаря этому я могу успешно зайти на мой сайт, используя:

example.com = 302 Moved Temporarily
www.example.com = 302 Moved Temporarily
http://example.com = 302 Moved Temporarily
http://www.example.com = 302 Moved Temporarily

Здесь не так уж много

https://example.com = Failed to connect to domain.com port 443: Connection refused

В настоящее время я проверяю, что мой сертификат SSL позволяет:

https://example.com
https://www.example.com

Кажется, что в документации так много говорится:

Secures: www.site.com and site.com

Буду очень признателен за понимание того, что я могу сделать неправильно, чтобы исправить это.

Спасибо.

Обновить: netstat -an | grep 443 выход:

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
unix 2 [ ACC ] STREAM LISTENING 6131379 /tmp/ssh-Cpqcfwspdv/agent.25443

3 ответа

Поскольку вы получаете сообщение об ошибке "Отказано в соединении" при наличии прослушивающего сокета на TCP /443, я бы сказал, что это определенно фильтр пакетов. Проверьте конфигурацию брандмауэра на хосте или, если он отключен, проверьте промежуточный брандмауэр в пути.

Спасибо @drookie и @Ginnungagap за ваше руководство. С этим я смог устранить подключения к серверу и настройки NGINX в качестве потенциальной причины. Окончательное решение было сделано в двух частях, часть из которых я получил от моего регистратора доменных имен namecheap. Решение было:

1) Создайте записи A, чтобы указать мой пустой домен (example.com) на IP-адрес моих серверов. 2) Обновите мою конфигурацию nginx, чтобы учесть трафик, идущий как на example.com, так и на www.example.com.

@Ginnungagap в попытке псевдо-конфигурации моего nginx в моем первоначальном вопросе, я напечатал свой proxy_pass директива неправильно. Это было передано http://myapp,

Я нашел более оптимизированный и более безопасный конфиг здесь конфиг nginx

Я адаптировал свой конфиг вокруг его (добавив дополнительные директивы безопасности SSL для хорошей меры), но в итоге он выглядел очень похожим.

Еще раз большое спасибо за ваше время и советы по этому вопросу.

Если ваша анонимность конфигурации NGINX верна, значит, proxy_pass Директива, скорее всего, неверна. В его текущем состоянии соединение с http://example.com перенаправляется на https://example.com где вы попали try_files директива, которая сначала пытается обслуживать файл из /var/www/ и если нет, передает запрос в указанное место @myapp,

И вот тут это выглядит странно для меня. Я думаю, что это должно быть удар по инстансу Gunicorn (вверх по течению myapp) но вместо этого он передает запрос http://domain в то время как это, скорее всего, должно быть передано http://myapp,

Это не объясняет, почему http://domain кажется преобразован в https://domain.com но в любом случае, я предлагаю вам попробовать.

Другие вопросы по тегам