Содержание
Создание самоподписанного SSL-сертификата для Nginx в Ubuntu 16.04
Мы покажем вам как создать сертификат, а также настроить веб-сервер Nginx для поддержки SSL
SSL (Secure Socket Layers) представляет собой криптографический протокол для защиты, передаваемых в интернете между клиентом и сервером. Протокол делает невозможным перехват данных злоумышленниками. SSL также помогают пользователям проверять подлинность посещаемые ресурсов. В этой статье мы покажем вам как можно сделать для веб-сервера Nginx на Ubuntu 16.04 самоподписанный сертификат.
Имейте ввиду, что такой SSL не способен подтвердить подлинность сервера из-за отсутствия подтверждения от специального сертификационного центра. Сертификат способен лишь обеспечивать шифрование канала передачи данных. Его можно применять пользователям без доменного имени. Если домен у вас уже есть, то SSL придется заверить в центре сертификации. Вы также можете получить от сервиса Let’s Encrypt бесплатный доверенный сертификат.
Нам потребуется:
- • Уже настроенный сервер Nginx;
- • Не-root пользователь, имеющий доступ к sudo.
1. Как создать сертификат?
SSL для работы применяет сочетание закрытого ключа и открытого сертификата. Ключ находится на сервере и доступа к нему нет. Сертификат же доступен всем пользователям, которые загружают контент с сервера. Для создания самоподписанного SSL и ключа нам нужно набрать в командной строке:
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). Это стандарт инфраструктуры для открытых ключей, для управления сертификатами;
- • Опция –x509 способна вносить поправки в предыдущую команду. Они сообщает о том, что нужно создать самоподписанный сертификат вместо запроса на его подпись;
- • -nodes служит для пропуска опции защиты SSL-сертификата с помощью пароля. Это необходимо для тог, чтобы Nginx при запуске считывал файл без необходимости вмешательства пользователя. Если поставить пароль – его нужно будет вводить после каждой перезагрузки;
- • Опция -days365 поможет задать срок действия сертификата;
- • Параметр -newkey rsa:2048 дает возможность сделать одновременно сертификат и ключ, ведь он не был создан ранее. Число 2048 значит, что ключ будет на 2048 бит;
- • Строка -keyout показывает, куда OpenSSL переместит полученный файл ключа;
- • Опция -out делает то же самое, но для сертификата.
С помощью вышеописанных опций вы сможете сгенерировать одновременно сертификат с ключом. Вам нужно лишь указать данные сервера, отображающиеся в SSL.
Строка common name очень важна. В нее нужно написать свое имя или полное доменное имя вашего сервера. Простыми словами: она нужна для связи с сервером доменного имени. Если его нет, укажите IР сервера. Поля будут выглядеть как-то так:
Country 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/nginx/ssl. Если применять OpenSSL, вам предстоит также сделать специальные ключи Диффи-Хеллмана для поддержки PFS. Чтобы это сделать, наберите в командной строке:
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Подождите несколько минут пока сгенерируются ключи. Они будут размещены в каталоге /etc/ssl/certs/dhparam.pem.
2.
Как настроить Nginx для поддержки SSL-сертификатов?
Созданные нами ключи хранятся в папке: /etc/ssl. Теперь нам нужно будет внести правки в настройки веб-сервера Nginx:
1) В первую очередь – создать сниппет, показывающий папку, в которой хранятся SSL и ключ. Новый сниппет для Nginx создаем в папке /etc/nginx/snippets. Мы советуем вам отразить его назначение в названии. Наберите в консоли:
sudo nano /etc/nginx/snippets/self-signed.conf
В файл добавим правило ssl_sertificate, указывающее путь к нашему сертификату. Кроме того, нам потребуется директива ssl_sertificate_key для пути к ключу:
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
2) Теперь потребуется добавить настройки сертификата с помощью еще одного сниппета. Это позволит нам получить надежный механизм шифрования с помощью дополнительных возможностей безопасности. Заданные параметры получится применять в будущих конфигурациях веб-сервера Nginx. Дайте файлу какое-нибудь общее имя:
sudo nano /etc/nginx/snippets/ssl-params.conf
Настроим DNS-распознаватель для запросов с восходящего канала, а также добавим ssl_dhparam для поддержки ключей Диффи-Хеллмана. Получится вот так:
# 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; add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; ssl_dhparam /etc/ssl/certs/dhparam.pem;
Учтите, что из-за самоподписанности сертификата, не будет использоваться SSL stapling. При этом сервер Nginx покажет предупреждение, выключит stapling для этого SSL и продолжит работать. Теперь сохраним изменения и закроем файл.
3) И последнее: настроить блоки server, чтобы они могли обслуживать запросы SSL и поддерживать новые настройки. В нашей статье рассматривается случай применения виртуального хоста default (блок server). Он хранится в папке /etc/nginx/sites-available. Если захотите пользоваться другим файлом, нужно указать его имя. Создадим резервную копию файла блока server с помощью:
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak
Теперь этот блок откроем в редакторе:
sudo nano /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. Если же вам требуется поддержка двух протоколов, то мы такой случай рассмотрим позже. Делим настройки на два отдельных блока. Правило server_name будет идти после двух директив listen. В нем требуется указать IP-адрес либо доменное имя. Ну, а на второй блок server настроим переадресацию. Имейте ввиду, что для настройки мы будем использовать временный редирект 302. Когда настройки будут правильные, можете смело задавать постоянный редирект 301. В файл добавим:
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; . . .
После этих строк нам предстоит добавить новый блок server для оставшихся настроек. Правило listen, использующее порт 443, нужно раскомментировать. Потом напишем правило http2 поддерживающее HTTP/2. Созданные ранее сниппеты нужно теперь просто выключить в файл. Помните, что в файле может существовать только одно правило listen, для комбинаций портов и IP-адресов, включающая модификатор default_server. Его нужно оставить только в одном блоке и удалить из остальных.
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, то объедините два блока server в один. Редирект же нужно удалить.
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 Available applications: Nginx Full Nginx HTTP Nginx HTTPS OpenSSH
Нам также нужно будет увидеть текущие настройки брандмауэра. Наберите в консоли:
sudo ufw status
Они будут выглядеть вот так, если поддерживается только трафик с протокола HTTP:
Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)
Нам же нужна поддержка и HTTPS. Для этого мы отключим профиль Nginx HTTP и настроим Nginx Full. Наберите в командной строке:
sudo ufw allow 'Nginx Full' sudo ufw delete allow 'Nginx HTTP'
Настройки брандмауэра изменятся и будут выглядеть вот так:
sudo ufw status Status: 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
Если все правильно, на экране вы увидите:
nginx: [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
Предупреждение появляется в первой строке, поскольку мы используем самоподписанный сертификат. Не обращайте внимания, соединение все равно будет корректно шифроваться. В случае обнаружения ошибок их необходимо исправить. После этого потребуется перезапуск веб-сервера Nginx с помощью:
sudo systemctl restart nginx
5. Тестируем настройки
Нам нужно убедиться, что трафик между клиентом и сервером шифруется. Это можно сделать, открыв в браузере ссылку:
https://домен_или_IP_сервера
Не удивляйтесь, если браузер сообщит, что сертификат ненадежный, ведь мы его подписали самостоятельно:
Your connection is not private Attackers might be trying to steal your information (for example, passwords,messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
Браузер не может проверить подлинность хоста, поэтому и выдает такое сообщение. Но нам нужно лишь шифрование соединения, которое сертификат нормально обеспечивает. Можно просто пропустить данное сообщение безопасности, нажав кнопку «Advanced», а также кликнув по показанной ссылке. Это даст вам доступ к вашему сайту. Нам нужно будет также проверить, работает ли переадресация трафика с HTTP на HTTPS, если ранее настраивали два блока server:
http://server_domain_or_IP
6. Как сделать постоянный редирект?
Если работа всех настроек сервера правильная, можно вместо временного редиректа ставить постоянный. Для этого откроем файл блока server:
sudo nano /etc/nginx/sites-available/default
В нем нужно найти return 302 и заменить значение на 301. Получится следующее:
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 сможет выполнять шифрование данных между клиентом и сервером. Это поможет вам защититься от хакерских атак передаваемого трафика. Чтобы предупреждения не появлялись, мы настоятельно рекомендуем вам все же подписать SSL в сертификационном центре.
Опубликовано: Июнь 19, 2017
Please enable JavaScript to view the comments powered by Disqus.SSL (https) в Nginx [Enchanted Technology]
nginx,
ssl,
https
nginx/1.4.6
Чтобы защитить передаваемый трафик между сервером и клиентом можно использоваться механизм SSL шифрования.
Так как nginx часто выступает в роли фронтенда, то шифрование возлагается на него.
Создание самоподписанного сертификата
Создадим папку где будем хранить сертификаты:
mkdir /etc/nginx/ssl chown root:root /etc/nginx/ssl chmod 700 /etc/nginx/ssl
Перейдем в эту папку и сгенерируем сертификат:
cd /etc/nginx/ssl openssl req -new -x509 -days 9999 -nodes -newkey rsa:2048 -out cert. https://$host$request_uri? permanent; } server { listen *:443 ssl; server_name my.site.com; ssl on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 исключить CVE-2014-3566 ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/cert.key; ... }
После настройки необходимо перезагрузить nginx
/etc/init.d/nginx reload
Всё готово, для доступа к сайту можно использовать HTTPS протокол
https://my.site.com
Так как сертификат самоподписанный, браузер попросит подтвердить исключение на его использование.
Создание сертификата командой:
openssl req -new -x509 -days 9999 -nodes -out cert.pem -keyout cert.key
запрашивает некоторую информацию для создания сертификата, заполнение которой можно пропустить.
Но если интересно вот описание параметров:
Значение | Описание | Обязательный параметр? |
---|---|---|
С | Двухсимвольный код страны (Country) | нет |
ST | Название региона/области/края/республики/… (State Name) | нет |
L | Название города/поселка/… (Locality Name) | нет |
O | Название организации (Organization Name) | нет |
OU | Название отдела (Organization Unit) | нет |
CN | Имя сертификата, при создании серверных сертификатов используется доменное имя сайта (Common Name) | да |
emailAddress | почтовый адрес (E-mail address) | нет |
Чтобы не вводить эти параметры интерактивное можно использовать опцию -subj:
openssl req -new -x509 -days 9999 -nodes -subj /C=RU/O=My\ site/CN=my. site.com/[email protected] -out cert.pem -keyout cert.key
Создайте самозаверяющий сертификат для Nginx за 5 минут
Как создать самозаверяющий сертификат SSL/TLS для Nginx
В этом руководстве я покажу вам, как создать самозаверяющий сертификат SSL/TLS и используйте его на Nginx за 5 минут или меньше. Я использую Ubuntu для этого урока, но если вы работаете в Mac OSX, вы можете следовать ему, так как синтаксис и команды почти идентичны.
Зачем создавать самозаверяющий сертификат?
Самозаверяющие сертификаты полезны для локальной разработки, когда вы хотите имитировать среду HTTPS. Обратите внимание, что самозаверяющие сертификаты не предназначены для производства, но они идеально подходят для разработки на локальном хосте.
Обзор создания самозаверяющего сертификата
Прежде чем продолжить, давайте сделаем шаг назад и рассмотрим шаги, связанные с созданием самозаверяющего сертификата для Nginx:
- Создание самозаверяющего сертификата с использованием OpenSSL
- Скопируйте сертификат в папку сертификатов в Ubuntu
- Обновите файл конфигурации Nginx, чтобы загрузить сертификат
- Скопируйте открытый ключ сертификата в доверенную корневую базу данных ЦС, чтобы Google Chrome не отображал сайт как небезопасный
Кроме того, я создал руководство на Youtube, в котором показано, как создать самозаверяющий сертификат для Nginx.
Посмотрите обучающее видео на Youtube
Шаг 1. Создание самозаверяющего сертификата с использованием OpenSSL
Я буду использовать OpenSSL для создания сертификата в Ubuntu. OpenSSL установлен на Mac OSX по умолчанию, и команды точно такие же.
OpenSSL создаст 2 файла, состоящих из закрытого и открытого ключа. Несмотря на то, что большинство людей называют сертификат SSL/TLS в единственном числе, сертификат представляет собой комбинацию закрытого ключа и открытого ключа.
Перед запуском команды OpenSSL для создания самозаверяющего сертификата я собираюсь создать файл конфигурации сертификата, в котором будут указаны биты сертификата и альтернативные имена субъекта. Альтернативные имена субъекта необходимы в Google Chrome 58 и более поздних версиях и используются для сопоставления доменного имени и сертификата. Если имя домена не указано в списке альтернативных имен субъектов сертификата, вы получите сообщение об ошибке NET::ERR_CERT_COMMON_NAME_INVALID .
Создайте файл конфигурации сертификата
sudo nano localhost.conf
[req] биты по умолчанию = 2048 default_keyfile = localhost.key отличительное_имя = req_distinguished_name req_extensions = req_ext x509_extensions = v3_ca [req_distinguished_name] countryName = название страны (двухбуквенный код) countryName_default = США stateOrProvinceName = название штата или провинции (полное название) stateOrProvinceName_default = Нью-Йорк localityName = Название местности (например, город) localityName_default = Рочестер OrganizationName = Название организации (например, компания) имя_организации_по умолчанию = локальный хост organizationUnitName = организационная единица organizationUnitName_default=Развитие commonName = Общее имя (например, полное доменное имя сервера или ВАШЕ имя) commonName_default = локальный хост общееИмя_макс = 64 [req_ext] subjectAltName = @alt_names [v3_ca] subjectAltName = @alt_names [alt_names] DNS.1 = локальный хост DNS.2 = 127.0.0.1
Создайте сертификат с помощью OpenSSL
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout localhost. key -out localhost.crt -config localhost.conf
Шаг 2. Скопируйте ключ сертификата Соедините папку Certificates в Ubuntu
Скопируйте открытый ключ в каталог /etc/ssl/certs
sudo cp localhost.crt /etc/ssl/certs/localhost.crt
Скопируйте закрытый ключ в каталог /etc/ ssl/частный каталог
sudo cp localhost.key /etc/ssl/private/localhost.key
Шаг 3. Обновите файл конфигурации Nginx, чтобы загрузить пару ключей сертификата
sudo nano /etc/nginx/sites-available/default
server { слушать 80; слушать 443 ssl http2; слушать [::]:443 ssl http2; имя_сервера локальный хост; ssl_certificate /etc/ssl/certs/localhost.crt; ssl_certificate_key /etc/ssl/private/localhost.key; ssl_protocols TLSv1.2 TLSv1.1 TLSv1; корень /var/www/html; индекс index.html index.nginx-debian.html; }
Перезагрузите изменения конфигурации Nginx
sudo service nginx reload
Откройте Google Chrome, чтобы убедиться, что Nginx загружает сайт через HTTP и HTTPS
Поскольку я не добавил самоподписанный сертификат в корневой каталог CA Chrome store, Chrome показывает сайт как небезопасный.
Google Chrome показывает сайт как небезопасный
Нажмите «Перейти к Localhost», чтобы убедиться, что Nginx правильно настроен
Nginx обслуживает самозаверяющие сертификаты, но Google Chrome показывает сайт как небезопасный
Шаг 4. Настройте Chrome так, чтобы он доверял сертификату и показывал сайт как безопасный
Добавьте сертификат в доверенное корневое хранилище ЦС
certutil -d sql:$HOME/.pki/nssdb -A -t "P, " -n "localhost" -i localhost.crt
Закройте все окна Google Chrome и снова откройте их. Теперь Chrome показывает сайт как безопасный.
Google Chrome показывает сайт как безопасный
Запуск Nginx Docker с самозаверяющим сертификатом SSL
Я пытаюсь запустить приложение пользовательского интерфейса с Docker, используя образ nginx Я могу без проблем получить доступ к службе через порт 80, но всякий раз, когда я пытаюсь получить к нему доступ через https на порту 443. Я не могу получить доступ к приложениям, которые сайт продолжает загружать, и в конечном итоге это приводит к недоступности. Я обновил файл nginx.conf в default.conf, чтобы разрешить доступ через порт 443
Ниже приведен мой nginx.conf
кодировка utf-8; сервер { слушать 80; имя_сервера локальный хост; корень /usr/nginx/html; } сервер { слушать 443; имя_сервера локальный хост; корень /usr/nginx/html; }
Я добавил самозаверяющий сертификат SSL в папку /usr/nginx и открыл порт 443 через файл Dockerfile
Ниже приведен мой файл Dockerfile
ИЗ nginx КОПИРОВАТЬ дист /usr/nginx/html ВЫПОЛНИТЬ chmod -R 777 /usr/nginx/html/* скопируйте nginx.conf /etc/nginx/conf.d/default.conf КОПИРОВАТЬ домен.crt /usr/nginx РАЗОБЛАЧЕНИЕ 80:443 ENTRYPOINT nginx -g 'демон выключен;'
Может ли кто-нибудь объяснить мне, что порт 443 не разрешает доступ
- докер
- nginx
- ssl
Чтобы сервер nginx разрешил шифрование SSL, вам необходимо указать флаг ssl при прослушивании в nginx.conf
и только ssl-сертификата будет недостаточно, вам также понадобятся ключ и пароль ssl-сертификата, и их необходимо настроить.
кодировка utf-8; сервер { слушать 80; имя_сервера локальный хост; корень /usr/share/nginx/html; } сервер { слушать 443 ssl; ssl_certificate /usr/nginx/ssl.crt; ssl_certificate_key /usr/nginx/ssl.key; файл_пароля_ssl /usr/nginx/ssl.pass; имя_сервера локальный хост; корень /usr/nginx/html; }
А ssl сертификат, ключ и пароль нужно поставить через тома или через встраивание в докер контейнер. Если вы запускаете контейнер в кластере kubernetes, лучше добавить их через секреты kubernetes.
Для Dockerfile вы можете добавить как
ИЗ nginx КОПИРОВАТЬ дист /usr/nginx/html ВЫПОЛНИТЬ chmod -R 777 /usr/nginx/html/* скопируйте nginx.conf /etc/nginx/conf.d/default.conf скопируйте ssl.crt /usr/nginx/ скопируйте ssl.pass /usr/nginx/ скопируйте ssl.key /usr/nginx/ РАЗОБЛАЧЕНИЕ 80:443 ENTRYPOINT nginx -g 'демон выключен;'
Для получения дополнительной информации вы можете обратиться к статье Nginx Docker https://medium.