Поиск по сайту:

SSL-сертификат Nginx и ошибки перенаправления HTTPS

Введение

Cerbot, чтобы помочь автоматизировать процесс получения сертификата и помочь в процессе перенаправления на HTTPS, все еще есть ошибки, которые могут возникнуть с вашим веб-сервером Nginx.

Примеры в этом руководстве были протестированы на сервере Ubuntu 22.04, но должны быть применимы к большинству установок Nginx. Большинство этих ошибок можно устранить с помощью стандартизированного файла конфигурации Nginx, хотя каталоги и пути могут незначительно отличаться.

В этом руководстве вы узнаете о распространенных ошибках, которые могут возникнуть при настройке сертификатов TLS/SSL и соединений перенаправления HTTPS для вашего сервера Nginx. Вы также узнаете, как определить возможные причины этих ошибок перенаправления и исправить их.

Проверка журнала ошибок Nginx

Ошибки и решения, представленные в этом руководстве, являются распространенными, но не исчерпывающими. Из-за характера синтаксических ошибок, нарушающих структуру того, что Nginx распознает как допустимые операторы, следующие ошибки являются лишь рекомендациями относительно того, как Nginx реагирует. Часто одна ошибка может перетекать в другую, а ошибка может быть симптомом более крупной или отдельной проблемы. Ваши конкретные обстоятельства и настройки могут отличаться.

Обратите внимание, что вы всегда можете обратиться к журналу ошибок Nginx, чтобы просмотреть текущий список:

  1. sudo cat /var/log/nginx/error.log

Проверка вашей директивы перенаправления для вашего блока сервера

Если у вас возникли проблемы с тем, что ваш веб-сайт не перенаправляется с HTTP на HTTPS, возможно, проблема связана с директивой, которую вы установили в файле конфигурации. В частности, директива listen должна указывать на соответствующий порт, в данном случае 443, что означает зашифрованный HTTPS-трафик. Для контекста, если вы настроили блок домена сервера для своего веб-сервера Nginx, ваша конфигурация может иметь следующую структуру:

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }
}

Содержимое этого файла предоставляет подробную информацию о нескольких директивах, но самая важная, на которую следует обратить внимание, — это директива listen. На данный момент эта директива разрешает входящие запросы только на порт 80, который используется по умолчанию для Nginx. Этот порт также предназначен для трафика HTTP, а не HTTPS. Чтобы разрешить перенаправление HTTP-трафика на HTTPS, необходимо обновить директиву listen, включив в нее порт 443.

Один из способов сделать это эффективно — получить сертификат TLS/SSL от центра сертификации (ЦС), такого как Let’s Encrypt. Наличие сертификата для вашего веб-сайта помогает включить шифрование HTTPS для веб-серверов.

Кроме того, получение и установка этого сертификата для Nginx полностью автоматизированы с помощью программного клиента Certbot, который имеет подключаемый модуль для Nginx. Вы можете разрешить Certbot автоматически настраивать файл конфигурации Nginx для перенаправления всего HTTP-трафика на HTTPS и запретить прямой HTTP-трафик. Вы также можете сделать это вручную, если хотите, и применяются те же принципы. Узнайте больше о том, как это сделать, из нашего руководства «Как защитить Nginx с помощью Let’s Encrypt». Для целей этого руководства мы получили сертификат через Let’s Encrypt, а файл конфигурации обновлен до следующего:

server {

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

        location / {
                try_files $uri $uri/ =404;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


}

server {
        if ($host = www.example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        if ($host = example.com) {
                return 301 https://$host$request_uri;
        } # managed by Certbot


        listen 80;
        listen [::]:80;

        server_name example.com www.example.com;
        return 404; # managed by Certbot
}

Если вы сравните этот блок домена сервера с первым примером, вы сможете оценить изменения, которые были сделаны в результате автоматизированных шагов, управляемых Certbot, для настройки SSL-сертификата. Что еще более важно, директива listen теперь указывает на порт 443, что означает, что соединения HTTPS разрешены. Сертификат и ключ, сгенерированные Certbot с помощью Let’s Encrypt, также теперь связаны с вашим серверным блоком.

Кроме того, Certbot реструктурирует ваш серверный блок, чтобы перенаправить весь HTTP-трафик на HTTPS. Теперь у вас есть дополнительный серверный блок, который обрабатывает исходную директиву прослушивания на порту 80. Этот новый блок сервера перехватывает весь трафик к вашим доменам, выполняя условную проверку переменной $host. Это выполняется с помощью условных операторов директивы if. Эти директивы проверяют, соответствует ли переменная вашим доменам, затем Nginx использует перенаправление 301 для отправки запроса на HTTPS-версию сайта. Более того, в качестве защиты от сбоев любой трафик, которому удастся пройти через условную переадресацию, будет перехвачен как ошибка 404.

Однако, если у вас все еще есть проблемы, вы можете проверить настройки брандмауэра и при необходимости изменить их.

Настройка параметров брандмауэра

Если ваш веб-браузер не отвечает даже после того, как вы настроили сертификат TLS/SSL, возможно, у вас проблема с настройками брандмауэра. Как упоминалось в предыдущем разделе, перенаправление с HTTP и HTTPS автоматически настраивается как директива listen в вашем файле конфигурации, если вы следовали руководству Let’s Encrypt. Таким образом, одной из возможных причин ошибки является то, что ваш брандмауэр не разрешает HTTPS-трафик через порт 443.

Чтобы проверить статус открытых в данный момент портов на вашем брандмауэре, вы можете запустить следующую команду. Имейте в виду, что в этом руководстве используется Uncomplicated Firewall, UFW, поэтому он может отличаться в зависимости от вашего дистрибутива:

  1. sudo ufw status



Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Если ваши выходные данные отражают список, подобный следующему, это означает, что ваш брандмауэр в настоящее время открыт только для приема запросов от HTTP. Чтобы настроить эти параметры, вы хотите добавить профиль Nginx HTTPS, который разрешает зашифрованный трафик TLS/SSL через порт 443. Для этого выполните следующую команду:

  1. sudo ufw allow 'Nginx HTTPS'

Если вы получили вывод Правило добавлено, значит, вы успешно добавили этот профиль в свой список. Вы можете подтвердить, проверив статус:

  1. sudo ufw status



Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
Nginx HTTPS                ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)
Nginx HTTPS (v6)           ALLOW       Anywhere (v6)

Примечание. Доступен профиль Nginx под названием Nginx Full, который открывает соединения портов HTTP и HTTPS. Если вы хотите очистить список, вы можете удалить два правила с помощью sudo ufw delete allow Nginx HTTP и sudo ufw delete allow Nginx HTTPS и добавить следующее правило:

  1. sudo ufw allow 'Nginx Full'

После этого ваш брандмауэр готов принимать соединения из HTTP- и HTTPS-трафика.

Теперь в списке указаны оба профиля Nginx HTTP и HTTPS, порт 443 открыт, и запросы будут перенаправляться на HTTPS.

Безопасная настройка перенаправления с помощью сертификата TLS/SSL

Перенаправление HTTP на HTTPS означает, что вы разрешаете соединения с зашифрованным трафиком, и это обычно подтверждается сертификатом TLS/SSL. Однако на уровне браузера все еще могут появляться сообщения об ошибках. Имейте в виду, что эти сообщения об ошибках не означают, что что-то не так с вашим сервером Nginx, а скорее с самим сертификатом.

Например, если вы используете самозаверяющий SSL-сертификат, он не проверяется центром сертификации (ЦС), таким как Let’s Encrypt. В результате, когда вы переходите в своем браузере по адресу https://example.com, скорее всего, появится сообщение с предупреждением для посетителей о том, что этот сайт небезопасен:

В этом сценарии возникает ошибка, которая гласит: «Ваше соединение не является частным» и имеет конкретную ошибку с указанием NET::ERR_CERT_AUTHORITY_INVALID. Это можно превзойти, несмотря на то, что сертификат не является безопасным, если вы нажмете опцию «Дополнительно»:

В расширенном варианте указано, что example.com не может быть правильно идентифицирован. Даже если это может быть неправдой, потому что вы настроили свой веб-сервер с самозаверяющим SSL-сертификатом, именно так он воспринимается всеми, кто посещает ваш сайт.

Несмотря на то, что вы можете продолжить работу на своем веб-сайте, нажав кнопку «Перейти к…», получение сообщения такого типа о безопасности и конфиденциальности при посещении вашего сайта является неудобным для пользователя. Вы захотите использовать сертификат, проверенный ЦС. Вы можете настроить это, прочитав наше руководство «Как защитить Nginx с помощью Let’s Encrypt».

Однако можно получить следующее сообщение, даже если у вас есть сертификат TLS/SSL, настроенный с помощью Let’s Encrypt:

Это сообщение отличается от исходного сообщения Ваше соединение не является частным, поскольку в сетевой ошибке указано NET::ERR_CERT_DATE_INVALID, что означает, что срок действия вашего текущего сертификата SSL/TLS истек. Важно отметить, что сертификат Let’s Encrypt действителен только в течение 90 дней. Если вы использовали пакет certbot при установке Let’s Encrypt, будет запланирована проверка сертификатов на истечение срока действия в течение следующих 30 дней, и она будет выполняться два раза в день через systemd.

Вы можете проверить состояние таймера следующим образом:

  1. sudo systemctl status snap.certbot.renew.service

Вывод подтвердит, что обновление вашего сертификата активно.

Однако, если срок действия вашего сертификата истек и вы хотите принудительно обновить его, вы можете сделать это с помощью следующей команды. Это также полезно сделать, если у вас есть разные домены, для которых вы хотите обновить сертификат:

  1. certbot certonly –force-renew -d example.com

Несмотря на то, что пакет certbot поставляется со сценарием обновления сертификата с /etc/cron.d, есть и другие варианты. Например, вы можете настроить параметр renew_hook в Certbot, чтобы вы могли запускать другие задачи после обновления. Для этого вам нужно добавить renew_hook в файл конфигурации обновления Certbot. Начните с открытия файла в предпочитаемом вами текстовом редакторе:

  1. sudo nano /etc/letsencrypt/renewal/example.com.conf

Как только вы окажетесь внутри файла, добавьте хук в последнюю строку, чтобы перезагрузить веб-службы, чтобы их можно было настроить для использования обновленного сертификата:

renew_hook = systemctl reload your_service

Когда вы закончите, вы можете сохранить и закрыть файл. Если вы используете nano, нажмите CTRL + X, Y, а затем ENTER.

Независимо от того, что вы выберете при настройке процесса обновления сертификата, вы всегда можете убедиться, что certbot выполняет процесс обновления, как предполагалось, с помощью следующей команды:

  1. sudo certbot renew --dry-run

Наконец, проверьте наличие синтаксических ошибок с помощью sudo nginx -t, а затем перезапустите Nginx с помощью sudo systemctl restart nginx, чтобы убедиться, что ваши изменения реализованы. После того, как вы все это сделали, перейдите в свой веб-браузер по адресу https://example.com, чтобы убедиться, что перенаправление работает правильно.

Заключение

В этом руководстве вы узнали, как устранять распространенные ошибки с перенаправлениями веб-сервера Nginx, в частности с HTTP на HTTPS. Некоторые из этих решений включают в себя проверку правильности настройки вашего файла конфигурации для прослушивания соответствующего порта, открытие брандмауэра для получения этих подключений и способы обработки сообщений об ошибках безопасности, которые вы можете получить относительно сертификатов SSL/TLS, которые не проверены или срок действия которых истек. . Если вам интересно узнать больше о Nginx, вы можете ознакомиться с нашей инструкцией по установке Nginx в Ubuntu 22.04.