TOC

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

Вступление

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

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

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

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

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

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

Предпосылки

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

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

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

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

Шаг 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/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-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 мы будем использовать рекомендацииRemy van Elst на сайтеCipherli.st. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения. Вы можете узнать больше о его решениях относительно выбора Nginxhere.

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

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

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

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

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

Наконец, вам следует уделить время чтениюHTTP Strict Transport Security, or HSTS и, в частности,“preload” functionality. Предварительная загрузка 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 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 Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Поскольку мы используем самозаверяющий сертификат, сшивание 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

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

/etc/nginx/sites-available/default

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-адрес. Затем мы настроим перенаправление на второй блок сервера, который будем создавать. После этого мы закроем этот короткий блок:

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

/etc/nginx/sites-available/default

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

    # SSL configuration

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

    . . .

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

[.note] #Note: У вас может быть только директиваonelisten, которая включает модификаторdefault_server для каждой версии IP и комбинации портов. Если у вас есть другие серверные блоки, включенные для этих портов, для которых установленdefault_server, вы должны удалить модификатор из одного из блоков.
#

/etc/nginx/sites-available/default

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

server {

    # SSL configuration

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

    . . .

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

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

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

/etc/nginx/sites-available/default

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

    server_name server_domain_or_IP;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    . . .

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

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

Шаг 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://server_domain_or_IP

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

Nginx self-signed cert warning

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

Nginx self-signed override

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

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

http://server_domain_or_IP

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

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

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

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

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

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

/etc/nginx/sites-available/default

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

. . .

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

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

sudo nginx -t

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

sudo systemctl restart nginx

Заключение

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

Related