TOC

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

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

Вступление

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

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

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

[.Примечание]##

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

Самозаверяющий сертификат может подойти, если у вас нет доменного имени, связанного с вашим сервером, и в случаях, когда зашифрованный веб-интерфейс не предназначен для пользователя. Если у васdo есть доменное имя, во многих случаях лучше использовать сертификат, подписанный ЦС. Вы можете узнать, как настроить бесплатный доверенный сертификат с помощью проекта Let’s Encrypthere.

Предпосылки

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

Вам также необходимо установить веб-сервер Nginx. Если вы хотите установить весь стек LEMP (Linux, Nginx, MySQL, PHP) на свой сервер, вы можете следовать нашему руководству поsetting up LEMP on Ubuntu 18.04.

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

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

[[step-1 -–- create-the-ssl-certificate]] == Шаг 1. Создание сертификата SSL

TLS/SSL works by using a combination of a public certificate and a private key. Ключ 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: эта подкоманда указывает, что мы хотим использовать управление запросом подписи сертификата (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, где разместить сертификат, который мы создаем.

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

Заполните соответствующие подсказки. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or, more likely, your server’s public IP address.с

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

OutputCountry Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

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

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

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

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

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

[[step-2 -–- configuring-nginx-to-use-ssl]] == Шаг 2. Настройка Nginx для использования SSL

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

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

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

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

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

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

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

Сначала давайте создадим новый фрагмент конфигурации Nginx в каталоге/etc/nginx/snippets.

Чтобы правильно определить назначение этого файла, назовем егоself-signed.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 мы будем использовать рекомендации Реми ван Элста на сайтеCipherli.st. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения.

[.Примечание]##

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

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

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

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

Во-вторых, мы закомментируем строку, которая устанавливает строгий заголовок безопасности транспорта. Прежде чем раскомментировать эту строку, вам следует уделить время чтениюHTTP Strict Transport Security, or HSTS и, в частности,“preload” functionality. Предварительная загрузка 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/example.com /etc/nginx/sites-available/example.com.bak

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

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

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

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

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

    server_name example.com www.example.com;

    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.

[.note] #Note: Мы будем использовать 302 редирект, пока не убедимся, что все работает правильно. Впоследствии мы можем изменить это на постоянное перенаправление 301.
#

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

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name example.com www.example.com;

    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 example.com www.example.com;

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

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

[[step-3 -–- adjusting-the-firewall]] == Шаг 3 - Настройка брандмауэра

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

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

sudo ufw app list

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

OutputAvailable applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

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

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)

[[step-4 -–- enable-the-changes-in-nginx]] == Шаг 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

[[step-5 -–- testing-encryption]] == Шаг 5. Тестирование шифрования

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

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

https://server_domain_or_IP

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

Nginx self-signed cert warning

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

Nginx self-signed override

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

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

http://server_domain_or_IP

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

[[шаг-6 -–- изменение-на-постоянное-перенаправление]] == Шаг 6 - Переход на постоянное перенаправление

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

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

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

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

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

    return 301 https://$server_name$request_uri;

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

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

sudo nginx -t

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

sudo systemctl restart nginx

Заключение

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

Related