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

Как создать самозаверяющий SSL-сертификат для Nginx в CentOS 7


Введение

TLS, или безопасность транспортного уровня, и его предшественник SSL, что означает уровень защищенных сокетов, — это веб-протоколы, используемые для переноса обычного трафика в защищенную зашифрованную оболочку.

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

В этом руководстве вы настроите самоподписанный SSL-сертификат для использования с веб-сервером Nginx на сервере CentOS 7.

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

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

Чтобы получить более готовое решение для сертификатов, ознакомьтесь с учебным пособием по настройке Nginx с сертификатом Let’s Encrypt в CentOS 7.

Предпосылки

Для выполнения этого руководства у вас должно быть следующее:

  • Сервер CentOS с пользователем без полномочий root, настроенным с привилегиями sudo, как описано в руководстве по начальной настройке сервера для CentOS 7.
  • На сервере установлен Nginx, как описано в разделе Установка Nginx в CentOS 7.

Когда вы будете готовы приступить к работе, войдите на свой сервер как пользователь sudo.

Шаг 1 — Создайте SSL-сертификат

TLS/SSL работает с использованием комбинации открытого сертификата и закрытого ключа. Ключ SSL хранится в секрете на сервере. Он используется для шифрования содержимого, отправляемого клиентам. SSL-сертификат общедоступен всем, кто запрашивает содержимое. Его можно использовать для расшифровки содержимого, подписанного соответствующим ключом SSL.

Каталог /etc/ssl/certs, который можно использовать для хранения общедоступного сертификата, уже должен существовать на сервере. Вам также потребуется создать каталог /etc/ssl/private для хранения файла закрытого ключа. Поскольку секретность этого ключа важна для безопасности, важно заблокировать разрешения для предотвращения несанкционированного доступа:

  1. sudo mkdir /etc/ssl/private
  2. sudo chmod 700 /etc/ssl/private

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

  1. sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Вам будет задан ряд вопросов. Прежде чем перейти к этому, давайте посмотрим, что происходит в команде:

  • openssl: это основной инструмент командной строки для создания сертификатов, ключей и других файлов OpenSSL и управления ими.
  • req: эта подкоманда указывает, что вы хотите использовать управление запросом на подпись сертификата (CSR) X.509. «X.509» — это стандарт инфраструктуры открытых ключей, которого придерживаются SSL и TLS для управления ключами и сертификатами. Вы хотите создать новый сертификат X.509, поэтому используете эту подкоманду.
  • -x509: это еще больше изменяет предыдущую подкоманду, сообщая утилите, что вы хотите создать самозаверяющий сертификат вместо создания запроса на подпись сертификата, как это обычно происходит.
  • -nodes: указывает OpenSSL пропустить возможность защиты вашего сертификата с помощью парольной фразы. Вам нужно, чтобы Nginx мог прочитать файл без вмешательства пользователя при запуске сервера. Парольная фраза предотвратит это, потому что вам придется вводить ее после каждого перезапуска.
  • -days 365: этот параметр устанавливает период времени, в течение которого сертификат будет считаться действительным. Вы устанавливаете его на один год здесь.
  • -newkey rsa:2048: указывает, что вы хотите создать новый сертификат и новый ключ одновременно. Вы не создали ключ, необходимый для подписи сертификата на предыдущем шаге, поэтому вам необходимо создать его вместе с сертификатом. Часть rsa:2048 указывает ему создать ключ RSA длиной 2048 бит.
  • -keyout: эта строка указывает OpenSSL, куда поместить сгенерированный файл закрытого ключа, который вы создаете.
  • -out: указывает OpenSSL, где разместить сертификат, который вы создаете.

Как указано выше, эти параметры будут создавать как файл ключа, так и сертификат. Вам будет задано несколько вопросов о вашем сервере, чтобы правильно встроить информацию в сертификат.

Заполните подсказки соответствующим образом. Самая важная строка — та, которая запрашивает Общее имя (например, полное доменное имя сервера или ВАШЕ имя). Вам необходимо ввести доменное имя, связанное с вашим сервером, или общедоступный IP-адрес вашего сервера.

В целом подсказки будут выглядеть примерно так:

Output
Country Name (2 letter code) [XX]:US State or Province Name (full name) []:Example Locality Name (eg, city) [Default City]:Example Organization Name (eg, company) [Default Company Ltd]:Example Inc Organizational Unit Name (eg, section) []:Example Dept Common Name (eg, your name or your server's hostname) []:your_domain_or_ip Email Address []:webmaster@example.com

Оба созданных вами файла будут помещены в соответствующие подкаталоги каталога /etc/ssl.

Поскольку вы используете OpenSSL, вам также следует создать сильную группу Диффи-Хеллмана, которая используется при согласовании совершенной секретности пересылки с клиентами.

Вы можете сделать это, набрав:

  1. sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Это может занять несколько минут, но когда это будет сделано, у вас будет сильная группа DH по адресу /etc/ssl/certs/dhparam.pem, которую вы сможете использовать в своей конфигурации.

Шаг 2 — Настройте Nginx для использования SSL

Конфигурация Nginx по умолчанию в CentOS довольно неструктурирована, а блок HTTP-сервера по умолчанию находится в основном файле конфигурации. Nginx проверит файлы, оканчивающиеся на .conf, в каталоге /etc/nginx/conf.d для дополнительной настройки.

Вы создадите новый файл в этом каталоге для настройки блока сервера, который будет обслуживать содержимое с помощью созданных вами файлов сертификатов. Затем вы можете дополнительно настроить блок сервера по умолчанию для перенаправления HTTP-запросов на HTTPS.

Создайте блок сервера TLS/SSL

Создайте и откройте файл с именем ssl.conf в каталоге /etc/nginx/conf.d:

  1. sudo vi /etc/nginx/conf.d/ssl.conf

Внутри начните с открытия блока server. По умолчанию соединения TLS/SSL используют порт 443, так что это должен быть ваш порт listen. В качестве server_name должно быть указано доменное имя или IP-адрес сервера, которые вы использовали в качестве общего имени при создании сертификата. Затем используйте директивы ssl_certificate, ssl_certificate_key и ssl_dhparam, чтобы задать расположение сгенерированных файлов SSL:

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
}

Далее вы добавите несколько дополнительных параметров SSL, которые повысят безопасность вашего сайта. Варианты, которые вы будете использовать, являются рекомендациями Cipherlist.eu. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения.

Примечание. Предлагаемые по умолчанию настройки на Cipherlist.eu обеспечивают надежную защиту. Иногда это происходит за счет большей совместимости клиентов. Если вам нужна поддержка старых клиентов, существует альтернативный список, доступ к которому можно получить, щелкнув ссылку с надписью «Да, дайте мне набор шифров, который работает с устаревшим/старым программным обеспечением».

Список совместимости можно использовать вместо предложений по умолчанию в приведенной выше конфигурации между двумя блоками комментариев. Выбор используемой конфигурации будет во многом зависеть от того, что вам нужно поддерживать.

Есть несколько частей конфигурации, которые вы можете изменить. Во-первых, вы можете добавить предпочитаемый преобразователь DNS для восходящих запросов в директиву resolver. Вы использовали Google для этого руководства, но вы можете изменить это, если у вас есть другие предпочтения.

Наконец, вы должны уделить немного времени, чтобы прочитать о функции «предварительной загрузки». Предварительная загрузка HSTS обеспечивает повышенную безопасность, но может иметь далеко идущие последствия, если она случайно или неправильно включена. В этом руководстве вы не будете предварительно загружать настройки, но вы можете измените это, если вы уверены, что понимаете последствия.

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
    ssl_prefer_server_ciphers on;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off; # Requires nginx >= 1.5.9
    ssl_stapling on; # Requires nginx >= 1.3.7
    ssl_stapling_verify on; # Requires nginx => 1.3.7
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    # Disable preloading HSTS for now.  You can use the commented out header line that includes
    # the "preload" directive if you understand the implications.
    #add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################
}

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

Наконец, добавьте остальную часть конфигурации Nginx для вашего сайта. Это будет отличаться в зависимости от ваших потребностей. Вы просто скопируете некоторые директивы, используемые в блоке местоположения по умолчанию для вашего примера, который установит корень документа и некоторые страницы ошибок:

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    . . .
    
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################

    root /usr/share/nginx/html;

    location / {
    }

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

Когда вы закончите, сохраните и выйдите. Это настраивает Nginx на использование созданного вами SSL-сертификата для шифрования трафика. Указанные параметры SSL гарантируют, что будут использоваться только самые безопасные протоколы и шифры. Обратите внимание, что этот пример конфигурации просто обслуживает страницу Nginx по умолчанию, поэтому вы можете изменить ее в соответствии со своими потребностями.

Создайте редирект с HTTP на HTTPS (необязательно)

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

К счастью, файл конфигурации Nginx по умолчанию позволяет нам легко добавлять директивы в серверный блок порта 80 по умолчанию. Вы можете сделать это, вставив это в начало ssl.conf:

server {
    listen 80;
    listen [::]:80;
    server_name your_server_ip;
    return 301 https://$host$request_uri;
}

. . .

Сохраните и закройте файл, когда закончите. Это настраивает блок сервера HTTP на порту 80 (по умолчанию) для перенаправления входящих запросов на настроенный вами блок сервера HTTPS.

Шаг 3 — Включите изменения в Nginx

Теперь, когда вы внесли изменения, вы можете перезапустить Nginx, чтобы реализовать новую конфигурацию.

Во-первых, вы должны убедиться, что в файлах конфигурации нет синтаксических ошибок. Вы можете сделать это, набрав:

  1. sudo nginx -t

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

Output
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

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

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

  1. sudo systemctl restart nginx

Процесс Nginx будет перезапущен с применением настроенных вами параметров SSL.

Шаг 4 — Тестовое шифрование

Теперь вы готовы протестировать свой SSL-сервер.

Откройте веб-браузер и введите https://, а затем доменное имя или IP-адрес вашего сервера в адресную строку:

https://server_domain_or_IP

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

Это ожидаемо и нормально. Вас интересует только аспект шифрования вашего сертификата, а не сторонняя проверка подлинности вашего хоста. Нажмите «ДОПОЛНИТЕЛЬНО», а затем ссылку, чтобы перейти к вашему хосту в любом случае:

Вас должны перенаправить на ваш сайт. Если вы посмотрите в адресную строку браузера, вы увидите некоторые признаки частичной безопасности. Это может быть замок со знаком \x над ним или треугольник с восклицательным знаком. В этом случае это просто означает, что сертификат не может быть проверен. Он все еще шифрует ваше соединение.

Если вы настроили Nginx для перенаправления HTTP-запросов на HTTPS, вы также можете проверить, правильно ли работает перенаправление:

http://server_domain_or_IP

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

Заключение

Вы настроили свой сервер Nginx для использования надежного шифрования для клиентских подключений. Это позволит вам безопасно обслуживать запросы и не позволит сторонним сторонам читать ваш трафик.