TOC

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

Вступление

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

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

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

Предпосылки

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

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

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

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

Шаг 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/ssl/certs/dhparam.pem 2048

Это может занять несколько минут, но когда это будет сделано, у вас будет сильная группа DH в + / etc / ssl / certs / 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 мы будем использовать рекомендации Remy van Elst на сайте https://cipherli.st [Cipherli.st]. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения. Вы можете прочитать больше о его решениях относительно выбора Nginx here.

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

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

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

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

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver  valid=300s;
resolver_timeout 5s;


add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

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

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

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

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

В этом руководстве мы будем предполагать, что вы используете файл блока сервера + default + в каталоге + / etc / nginx / sites-available +. Если вы используете другой файл блока сервера, подставьте его имя в приведенные ниже команды.

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

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

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

sudo nano /etc/nginx/sites-available/default

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

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

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

   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

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

Мы будем разбивать конфигурацию на два отдельных блока. После двух первых директив + listen + мы добавим директиву + server_name +, указав имя домена вашего сервера или, что более вероятно, IP-адрес. Затем мы настроим перенаправление на второй блок сервера, который будем создавать. После этого мы закроем этот короткий блок:

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

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




   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

Далее нам нужно запустить новый блок сервера непосредственно ниже, чтобы содержать оставшуюся конфигурацию. Мы можем раскомментировать две директивы + listen +, которые используют порт 443. После этого нам просто нужно включить два файла фрагмента, которые мы настроили:

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name ;
   return 302 https://$server_name$request_uri;
}



   # SSL configuration






   . . .

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

(Альтернативная конфигурация) Разрешить трафик HTTP и HTTPS

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

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

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



   server_name ;



   . . .

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

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

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

UFW

Если вы используете * ufw *, вы можете увидеть текущие настройки, набрав:

sudo ufw status

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

OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW                        ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

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

sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'

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

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

Запросы HTTPS теперь должны приниматься вашим сервером.

IPTables

Если вы используете + iptables +, вы можете увидеть текущие правила, набрав:

sudo iptables -S

Если у вас есть какие-либо правила, они будут отображаться. Пример конфигурации может выглядеть так:

Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Команды, необходимые для открытия трафика SSL, будут зависеть от ваших текущих правил. Для базового набора правил, подобного приведенному выше, вы можете добавить доступ SSL, набрав:

sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT

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

sudo iptables -S
Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

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

Шаг 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

Наш сервер теперь должен быть доступен через HTTPS.

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

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

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

https://

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

изображение: 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/default

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

/ И т.д. / Nginx / сайты-отсутствуют / по умолчанию

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name ;
   return  https://$server_name$request_uri;
}

. . .

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

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

sudo nginx -t

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

sudo systemctl restart nginx

Ваш сайт теперь должен выдавать постоянное перенаправление при доступе через HTTP.

Заключение

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

Related