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

Вступление

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

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

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

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

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

Самозаверяющий сертификат может подойти, если у вас нет доменного имени, связанного с вашим сервером, и в случаях, когда зашифрованный веб-интерфейс не предназначен для пользователя. Если у васdo есть доменное имя, во многих случаях лучше использовать сертификат, подписанный ЦС. Чтобы узнать, как настроить бесплатный доверенный сертификат, следуйте нашему руководству поsetting up Nginx with a Let’s Encrypt certificate on CentOS 7.

Предпосылки

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

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

Шаг 1: Установите Nginx и настройте брандмауэр

Прежде чем начать, мы должны убедиться, что на нашей машине установлен веб-сервер Nginx.

Хотя Nginx недоступен в репозиториях CentOS по умолчанию, онis присутствует в репозитории EPEL (дополнительные пакеты для Enterprise Linux). Мы можем включить репозиторий EPEL, чтобы предоставить нашему серверу доступ к пакету Nginx, введя:

sudo yum install epel-release

Далее мы можем установить Nginx, набрав:

sudo yum install nginx

Запустите сервис Nginx, набрав:

sudo systemctl start nginx

Убедитесь, что служба запущена и работает, набрав:

systemctl status nginx

Output● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-01-06 17:27:50 UTC; 28s ago

. . .

Jan 06 17:27:50 centos-512mb-nyc3-01 systemd[1]: Started The nginx HTTP and reverse proxy server.

Вы также захотите включить Nginx, чтобы он запускался при загрузке вашего сервера:

sudo systemctl enable nginx

OutputCreated symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

Далее нам нужно убедиться, что мы не блокируем доступ к портам 80 и 443 с помощью брандмауэра. Если вы не используете брандмауэр, вы можете перейти к следующему разделу.

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

sudo firewall-cmd --add-service=http
sudo firewall-cmd --add-service=https
sudo firewall-cmd --runtime-to-permanent

Если у вас запущен брандмауэрiptables, команды, которые вам нужно запустить, сильно зависят от вашего текущего набора правил. Для базового набора правил вы можете добавить доступ по HTTP и HTTPS, набрав:

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

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

Шаг 2: Создайте сертификат SSL

TLS/SSL works by using a combination of a public certificate and a private key. Ключ SSL хранится в секрете на сервере. Он используется для шифрования контента, отправляемого клиентам. Сертификат SSL является общедоступным для всех, кто запрашивает контент. Его можно использовать для расшифровки содержимого, подписанного соответствующим ключом SSL.

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

sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private

Теперь мы можем создать самоподписанный ключ и пару сертификатов с 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 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, которую мы можем использовать в нашей конфигурации.

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

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

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

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

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

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

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

/etc/nginx/conf.d/ssl.conf

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

    server_name server_IP_address;

    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, которые повысят безопасность нашего сайта. Опции, которые мы будем использовать, являются рекомендациямиRemy van Elst на сайтеCipherli.st. Этот сайт предназначен для предоставления простых в использовании настроек шифрования для популярного программного обеспечения. Вы можете узнать больше о его решениях относительно выбора Nginx, прочитавStrong SSL Security on nginx.

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

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

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

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

Наконец, вы должны уделить время чтениюHTTP Strict Transport Security, or HSTS и, в частности,“preload” functionality. Предварительная загрузка HSTS обеспечивает повышенную безопасность, но может иметь далеко идущие последствия, если ее случайно включить или включить неправильно. В этом руководстве мы не будем предварительно загружать настройки, но вы можете изменить их, если уверены, что понимаете последствия.

/etc/nginx/conf.d/ssl.conf

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

    server_name server_IP_address;

    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://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;

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################
}

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

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

/etc/nginx/conf.d/ssl.conf

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

    server_name server_IP_address;

    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://cipherli.st/                                            #
    # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html #
    ########################################################################

    . . .

    ##################################
    # END https://cipherli.st/ 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 по умолчанию, добавляя файлы в каталог/etc/nginx/default.d. Создайте новый файл с именемssl-redirect.conf и откройте его для редактирования с помощью этой команды:

sudo vi /etc/nginx/default.d/ssl-redirect.conf

Затем вставьте в эту строку:

/etc/nginx/default.d/ssl-redirect.conf

return 301 https://$host$request_uri/;

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

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

Процесс Nginx будет перезапущен с настройками SSL, которые мы настроили.

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

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

Заключение

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

TOC

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

Вступление

Предпосылки

Шаг 1: Установите Nginx и настройте брандмауэр

Шаг 2: Создайте сертификат SSL

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

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

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

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

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

Заключение

Related