Назад | Перейти на главную страницу

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

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

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

@Ginnungagap the, пытаясь псевдо-конфигурацию 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 но в любом случае, я предлагаю вам попробовать.

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