Как создать самоподписанный сертификат SSL для Nginx в Debian 9

_ Предыдущая версия этого руководства была написана Justin Ellingwood _

Вступление

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

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

В этом руководстве мы покажем вам, как настроить самозаверяющий SSL-сертификат для использования с веб-сервером Nginx на сервере Debian 9.

Предпосылки

Прежде чем начать, у вас должен быть пользователь без полномочий root, настроенный с привилегиями + sudo +. Вы можете узнать, как настроить такую ​​учетную запись пользователя, следуя нашим initial настройкам сервера для Debian 9.

Вам также необходимо установить веб-сервер Nginx. Если вы хотите установить на свой сервер весь стек LEMP (Linux, Nginx, MySQL, PHP), вы можете следовать нашему руководству по адресу https://www.digitalocean.com/community/tutorials/how-to-install-linux. -nginx-mysql-php-lemp-stack-debian-9 [настройка LEMP в Debian 9].

Если вам нужен только веб-сервер Nginx, вы можете вместо этого следовать нашему руководству на installing Nginx на Debian 9 ,

Когда вы выполнили необходимые условия, продолжайте ниже.

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

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

Мы можем создать самоподписанный ключ и пару сертификатов с OpenSSL в одной команде:

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 *: эта подкоманда указывает, что мы хотим использовать управление запросом подписи сертификата X.509 (CSR). «X.509» - это стандарт инфраструктуры открытых ключей, которого придерживаются SSL и TLS для управления ключами и сертификатами. Мы хотим создать новый сертификат X.509, поэтому мы используем эту подкоманду.

  • * -x509 *: Это дополнительно изменяет предыдущую подкоманду, сообщая утилите, что мы хотим сделать самозаверяющий сертификат вместо генерации запроса на подпись сертификата, как это обычно происходит.

  • * -nodes *: Это говорит OpenSSL пропустить опцию для защиты нашего сертификата парольной фразой. Нам нужно, чтобы Nginx мог читать файл без вмешательства пользователя при запуске сервера. Парольная фраза предотвратит это, потому что мы должны будем вводить ее после каждого перезапуска.

  • * -days 365 *: эта опция устанавливает период времени, в течение которого сертификат будет считаться действительным. Мы установили это на один год здесь.

  • * -newkey rsa: 2048 *: указывает, что мы хотим создать новый сертификат и новый ключ одновременно. Мы не создали ключ, необходимый для подписи сертификата на предыдущем шаге, поэтому нам нужно создать его вместе с сертификатом. Часть + rsa: 2048 + говорит ему сделать ключ RSA длиной 2048 бит.

  • * -keyout *: эта строка сообщает OpenSSL, куда поместить созданный нами файл закрытого ключа.

  • * -out *: Это сообщает OpenSSL, где разместить сертификат, который мы создаем.

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

Заполните соответствующие подсказки. * Самая важная строка - это та, которая запрашивает `+ Common Name (например, FQDN сервера или ВАШЕ имя) + `. Вам необходимо ввести доменное имя, связанное с вашим сервером, или, более вероятно, публичный IP-адрес вашего сервера. *

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

OutputCountry Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

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

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

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

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

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

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

Мы создали наши файлы ключей и сертификатов в каталоге + / etc / ssl +. Теперь нам просто нужно изменить нашу конфигурацию Nginx, чтобы воспользоваться этими преимуществами.

Мы внесем несколько изменений в нашу конфигурацию.

  1. Мы создадим фрагмент конфигурации, содержащий наш ключ SSL и расположение файла сертификата.

  2. Мы создадим фрагмент конфигурации, содержащий строгие настройки SSL, которые могут быть использованы с любыми сертификатами в будущем.

  3. Мы настроим наши серверные блоки Nginx для обработки запросов SSL и будем использовать два приведенных выше фрагмента.

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

Создание фрагмента конфигурации, указывающего на ключ SSL и сертификат

Во-первых, давайте создадим новый фрагмент конфигурации Nginx в каталоге + / etc / nginx / snippets +.

Чтобы правильно определить назначение этого файла, давайте назовем его + self-signature.conf +:

sudo nano /etc/nginx/snippets/self-signed.conf

В этом файле нам нужно установить директиву + ssl_certificate для вашего файла сертификата, а ключ` + ssl_certificate_key` - для соответствующего ключа. В нашем случае это будет выглядеть так:

/etc/nginx/snippets/self-signed.conf

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

Когда вы добавите эти строки, сохраните и закройте файл.

Создание фрагмента конфигурации с надежными настройками шифрования

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

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

sudo nano /etc/nginx/snippets/ssl-params.conf

Для безопасной настройки Nginx SSL мы будем использовать рекомендации Реми ван Элста на сайте https://cipherli.st [Cipherli.st]. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения.

Для наших целей мы можем скопировать предоставленные настройки в полном объеме. Нам просто нужно сделать несколько небольших модификаций.

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

Во-вторых, мы закомментируем строку, которая устанавливает строгий заголовок безопасности транспорта. Перед тем, как раскомментировать эту строку, вы должны уделить немного времени чтению на HTTP Strict Transport Security или HSTS, в частности, о https://hstspreload.appspot.com / [Функциональность «предварительной загрузки»]. Предварительная загрузка HSTS обеспечивает повышенную безопасность, но может иметь далеко идущие последствия, если ее случайно включить или включить неправильно.

Скопируйте следующее в ваш файл + ssl-params.conf +:

/etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
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 strict transport security for now. You can uncomment the following
# line 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";

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

Сохраните и закройте файл, когда вы закончите.

Настройка конфигурации Nginx для использования SSL

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

В этом руководстве мы предполагаем, что вы используете пользовательский файл конфигурации блока сервера в каталоге + / etc / nginx / sites-available +. Для этого примера мы будем использовать + / etc / nginx / sites-available / example.com +. Замените ваше имя файла конфигурации при необходимости.

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

sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/.bak

Теперь откройте файл конфигурации, чтобы внести изменения:

sudo nano /etc/nginx/sites-available/

Внутри ваш серверный блок, вероятно, начинается примерно так:

/etc/nginx/sites-available/example.com

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

   server_name ;

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

   . . .
}

Ваш файл может быть в другом порядке, и вместо директив + root + и + index + у вас могут быть некоторые + location,` + proxy_pass` или другие пользовательские операторы конфигурации. Это нормально, так как нам нужно только обновить директивы + listen + и включить наши фрагменты SSL. Мы будем модифицировать этот существующий блок сервера для обслуживания трафика SSL через порт 443, затем создадим новый блок сервера для ответа на порт 80 и автоматически перенаправим трафик на порт 443.

В существующем файле конфигурации обновите два оператора + listen +, чтобы использовать порт 443 и SSL, а затем включите два файла фрагмента, которые мы создали на предыдущих шагах:

/etc/nginx/sites-available/example.com

server {
   listen ;
   listen [::]:;



   server_name ;

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

   . . .
}

Затем вставьте второй блок сервера в файл конфигурации после закрывающей скобки (+} +) первого блока:

/etc/nginx/sites-available/example.com

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

   server_name ;

   return 302 https://$server_name$request_uri;
}

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

Шаг 3 - Настройка брандмауэра

Если у вас включен брандмауэр + ufw +, как рекомендовано в обязательных руководствах, вам необходимо изменить настройки, чтобы разрешить трафик SSL. К счастью, Nginx регистрирует несколько профилей с помощью + ufw + после установки.

Мы можем увидеть доступные профили, набрав:

sudo ufw app list

Вы должны увидеть такой список:

OutputAvailable applications:
. . .
 Nginx Full
 Nginx HTTP
 Nginx HTTPS
. . .

Вы можете увидеть текущие настройки, набрав:

sudo ufw status

Вероятно, это будет выглядеть так, что означает, что веб-серверу разрешен только HTTP-трафик:

OutputStatus: active

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

Чтобы дополнительно разрешить HTTPS-трафик, мы можем разрешить профиль «Nginx Full», а затем удалить избыточный допуск профиля «Nginx HTTP»:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

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

sudo ufw status
OutputStatus: active

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

Шаг 4 - Включение изменений в Nginx

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

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

sudo nginx -t

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

Outputnginx: [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 для реализации наших изменений:

sudo systemctl restart nginx

Шаг 5 - Тестирование шифрования

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

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

https://

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

изображение: https: //assets.digitalocean.com/articles/nginx_ssl_1604/self_signed_warning.png [Самоподписанное предупреждение сертификата Nginx]

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

изображение: https: //assets.digitalocean.com/articles/nginx_ssl_1604/warning_override.png [Самоподписанное переопределение Nginx]

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

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

http://

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

Шаг 6 - Переход на постоянное перенаправление

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

Снова откройте файл конфигурации блока сервера:

sudo nano /etc/nginx/sites-available/

Найдите + return 302 + и измените его на + return 301 +:

/etc/nginx/sites-available/example.com

   return  https://$server_name$request_uri;

Сохраните и закройте файл.

Проверьте вашу конфигурацию на наличие синтаксических ошибок:

sudo nginx -t

Когда вы будете готовы, перезапустите Nginx, чтобы сделать перенаправление постоянным:

sudo systemctl restart nginx

Заключение

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

Related