- Генерация самоподписанного сертификата ssl linux nginx
- 1. Как создать сертификат?
- 2. Как настроить Nginx для поддержки SSL-сертификатов?
- 3. Как настроить брандмауэр?
- 4. Как обновить настройки Nginx
- 5. Тестируем настройки
- 6. Как сделать постоянный редирект?
- Навигация
- SSL (https) в Nginx
- Создание самоподписанного сертификата
- Настройка
- Дополнительные опции создания SSL-сертификата
- Авторизация клиентов в nginx посредством SSL сертификатов
- Введение:
- Шаг 1. Создание собственного самоподписанного доверенного сертификата.
- Шаг 2. Сертификат сервера
- Шаг 3. Создание клиентских сертификатов
- Использованное ПО
Генерация самоподписанного сертификата ssl linux nginx
- Главная
- Блог
- Администрирование
- Создание самоподписанного SSL-сертификата для Nginx в Ubuntu 16.04
Создание самоподписанного 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 и ключа нам нужно набрать в командной строке:
На экране вы увидите несколько вопросов. Из компонентов команды можно выделить:
- • Openssl – это базовый инструмент командной строки. Он нужен для создания и управления сертификатами, а также файлами OpenSSL и ключами;
- • Подкоманда req показывает, что требуется запрос для подписи сертификата X.509 (CSR). Это стандарт инфраструктуры для открытых ключей, для управления сертификатами;
- • Опция –x509 способна вносить поправки в предыдущую команду. Они сообщает о том, что нужно создать самоподписанный сертификат вместо запроса на его подпись;
- • -nodes служит для пропуска опции защиты SSL-сертификата с помощью пароля. Это необходимо для тог, чтобы Nginx при запуске считывал файл без необходимости вмешательства пользователя. Если поставить пароль – его нужно будет вводить после каждой перезагрузки;
- • Опция -days365 поможет задать срок действия сертификата;
- • Параметр -newkey rsa:2048 дает возможность сделать одновременно сертификат и ключ, ведь он не был создан ранее. Число 2048 значит, что ключ будет на 2048 бит;
- • Строка -keyout показывает, куда OpenSSL переместит полученный файл ключа;
- • Опция -out делает то же самое, но для сертификата.
С помощью вышеописанных опций вы сможете сгенерировать одновременно сертификат с ключом. Вам нужно лишь указать данные сервера, отображающиеся в SSL.
Строка common name очень важна. В нее нужно написать свое имя или полное доменное имя вашего сервера. Простыми словами: она нужна для связи с сервером доменного имени. Если его нет, укажите IР сервера. Поля будут выглядеть как-то так:
Обратите внимание, что файлы сертификата и ключа будут перемещены в папку /etc/nginx/ssl. Если применять OpenSSL, вам предстоит также сделать специальные ключи Диффи-Хеллмана для поддержки PFS. Чтобы это сделать, наберите в командной строке:
Подождите несколько минут пока сгенерируются ключи. Они будут размещены в каталоге /etc/ssl/certs/dhparam.pem.
2. Как настроить Nginx для поддержки SSL-сертификатов?
Созданные нами ключи хранятся в папке: /etc/ssl. Теперь нам нужно будет внести правки в настройки веб-сервера Nginx:
1) В первую очередь – создать сниппет, показывающий папку, в которой хранятся SSL и ключ. Новый сниппет для Nginx создаем в папке /etc/nginx/snippets. Мы советуем вам отразить его назначение в названии. Наберите в консоли:
В файл добавим правило ssl_sertificate, указывающее путь к нашему сертификату. Кроме того, нам потребуется директива ssl_sertificate_key для пути к ключу:
2) Теперь потребуется добавить настройки сертификата с помощью еще одного сниппета. Это позволит нам получить надежный механизм шифрования с помощью дополнительных возможностей безопасности. Заданные параметры получится применять в будущих конфигурациях веб-сервера Nginx. Дайте файлу какое-нибудь общее имя:
Настроим DNS-распознаватель для запросов с восходящего канала, а также добавим ssl_dhparam для поддержки ключей Диффи-Хеллмана. Получится вот так:
Учтите, что из-за самоподписанности сертификата, не будет использоваться SSL stapling. При этом сервер Nginx покажет предупреждение, выключит stapling для этого SSL и продолжит работать. Теперь сохраним изменения и закроем файл.
3) И последнее: настроить блоки server, чтобы они могли обслуживать запросы SSL и поддерживать новые настройки. В нашей статье рассматривается случай применения виртуального хоста default (блок server). Он хранится в папке /etc/nginx/sites-available. Если захотите пользоваться другим файлом, нужно указать его имя. Создадим резервную копию файла блока server с помощью:
Теперь этот блок откроем в редакторе:
Он будет выглядеть где-то так:
Перенаправим незашифрованные HTTP-запросы на HTTPS. Если же вам требуется поддержка двух протоколов, то мы такой случай рассмотрим позже. Делим настройки на два отдельных блока. Правило server_name будет идти после двух директив listen. В нем требуется указать IP-адрес либо доменное имя. Ну, а на второй блок server настроим переадресацию. Имейте ввиду, что для настройки мы будем использовать временный редирект 302. Когда настройки будут правильные, можете смело задавать постоянный редирект 301. В файл добавим:
После этих строк нам предстоит добавить новый блок server для оставшихся настроек. Правило listen, использующее порт 443, нужно раскомментировать. Потом напишем правило http2 поддерживающее HTTP/2. Созданные ранее сниппеты нужно теперь просто выключить в файл. Помните, что в файле может существовать только одно правило listen, для комбинаций портов и IP-адресов, включающая модификатор default_server. Его нужно оставить только в одном блоке и удалить из остальных.
Изменения нужно сохранить, а файл – закрыть. Если нужно настроить одновременную поддержку HTTP и HTTPS, то объедините два блока server в один. Редирект же нужно удалить.
Эти изменения нужно сохранить. После этого закрывайте файл.
3. Как настроить брандмауэр?
Мы будем настраивать брандмауэр ufw для поддержки SSL-трафика. При инсталляции Nginx проводит регистрацию нескольких профилей в ufw. Вы можете просмотреть доступные с помощью команд:
Нам также нужно будет увидеть текущие настройки брандмауэра. Наберите в консоли:
Они будут выглядеть вот так, если поддерживается только трафик с протокола HTTP:
Нам же нужна поддержка и HTTPS. Для этого мы отключим профиль Nginx HTTP и настроим Nginx Full. Наберите в командной строке:
Настройки брандмауэра изменятся и будут выглядеть вот так:
4. Как обновить настройки Nginx
После корректировки настроек веб-сервера и брандмауэра нужно перезапустить Nginx, чтобы все изменения вступили в силу. Проверьте синтаксис на наличие ошибок с помощью:
Если все правильно, на экране вы увидите:
Предупреждение появляется в первой строке, поскольку мы используем самоподписанный сертификат. Не обращайте внимания, соединение все равно будет корректно шифроваться. В случае обнаружения ошибок их необходимо исправить. После этого потребуется перезапуск веб-сервера Nginx с помощью:
5. Тестируем настройки
Нам нужно убедиться, что трафик между клиентом и сервером шифруется. Это можно сделать, открыв в браузере ссылку:
Не удивляйтесь, если браузер сообщит, что сертификат ненадежный, ведь мы его подписали самостоятельно:
Браузер не может проверить подлинность хоста, поэтому и выдает такое сообщение. Но нам нужно лишь шифрование соединения, которое сертификат нормально обеспечивает. Можно просто пропустить данное сообщение безопасности, нажав кнопку «Advanced», а также кликнув по показанной ссылке. Это даст вам доступ к вашему сайту. Нам нужно будет также проверить, работает ли переадресация трафика с HTTP на HTTPS, если ранее настраивали два блока server:
6. Как сделать постоянный редирект?
Если работа всех настроек сервера правильная, можно вместо временного редиректа ставить постоянный. Для этого откроем файл блока server:
В нем нужно найти return 302 и заменить значение на 301. Получится следующее:
Изменения в файле нужно сохранить и закрыть его. Не забудьте проверить синтаксис на предмет содержания ошибок. Для это потребуется команда:
Если все правильно, Nginx можно перезапустить с помощью:
После выполнения всех вышеописанных действий, сервер Nginx сможет выполнять шифрование данных между клиентом и сервером. Это поможет вам защититься от хакерских атак передаваемого трафика. Чтобы предупреждения не появлялись, мы настоятельно рекомендуем вам все же подписать SSL в сертификационном центре.
Источник
Навигация
SSL (https) в Nginx
Чтобы защитить передаваемый трафик между сервером и клиентом можно использоваться механизм SSL шифрования.
Так как nginx часто выступает в роли фронтенда, то шифрование возлагается на него.
Создание самоподписанного сертификата
Создадим папку где будем хранить сертификаты:
Перейдем в эту папку и сгенерируем сертификат:
При генерации вас попросят указать некоторые данные, так как мы создаем сертификат для себя то заполнять их не обязательно. Настроим использование одного самоподписанного сертификата для нескольких сайтов.
Настройка
Теперь для конфигурации хоста с поддержкой шифрования будем использовать следующий шаблон:
таким образом можно работать как по HTTP так и HTTPS
Пример с принудительным использованием HTTPS
После настройки необходимо перезагрузить nginx
Всё готово, для доступа к сайту можно использовать HTTPS протокол
Так как сертификат самоподписанный, браузер попросит подтвердить исключение на его использование.
Дополнительные опции создания SSL-сертификата
Создание сертификата командой:
запрашивает некоторую информацию для создания сертификата, заполнение которой можно пропустить.
Но если интересно вот описание параметров:
Значение | Описание | Обязательный параметр? |
---|---|---|
С | Двухсимвольный код страны (Country) | нет |
ST | Название региона/области/края/республики/… (State Name) | нет |
L | Название города/поселка/… (Locality Name) | нет |
O | Название организации (Organization Name) | нет |
OU | Название отдела (Organization Unit) | нет |
CN | Имя сертификата, при создании серверных сертификатов используется доменное имя сайта (Common Name) | да |
emailAddress | почтовый адрес (E-mail address) | нет |
Чтобы не вводить эти параметры интерактивное можно использовать опцию -subj:
Источник
Авторизация клиентов в nginx посредством SSL сертификатов
Введение:
Потребовалось мне тут как-то написать небольшой API, в котором необходимо было помимо обычных запросов принимать запросы с «высокой степенью секретности».
Не я первый с этим столкнулся и мир давно уже использует для таких вещей SSL.
Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.
Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.
Внимание! В статье для примера используются самоподписанные сертификаты!
Перед стартом создадим папку в конфиге nginx, где будут плоды наших трудов:
Шаг 1. Создание собственного самоподписанного доверенного сертификата.
Собственный доверенный сертификат (Certificate Authority или CA) необходим для подписи клиентских сертификатов и для их проверки при авторизации клиента веб-сервером.
С помощью приведенной ниже команды создается закрытый ключ и самоподписанный сертификат.
req Запрос на создание нового сертификата.
-new Создание запроса на сертификат (Certificate Signing Request – далее CSR).
-newkey rsa:1023 Автоматически будет создан новый закрытый RSA ключ длиной 1024 бита. Длину ключа можете настроить по своему усмотрению.
-nodes Не шифровать закрытый ключ.
-keyout ca.key Закрытый ключ сохранить в файл ca.key.
-x509 Вместо создания CSR (см. опцию -new) создать самоподписанный сертификат.
-days 500 Срок действия сертификата 500 дней. Размер периода действия можете настроить по своему усмотрению. Не рекомендуется вводить маленькие значения, так как этим сертификатом вы будете подписывать клиентские сертификаты.
-subj /C=RU/ST=Moscow/L=Moscow/O=Companyname/OU=User/CN=etc/emailAddress=support@site.com
Данные сертификата, пары параметр=значение, перечисляются через ‘/’. Символы в значении параметра могут быть «подсечены» с помощью обратного слэша «\», например «O=My\ Inc». Также можно взять значение аргумента в кавычки, например, -subj «/xx/xx/xx».
Шаг 2. Сертификат сервера
Создадим сертификат для nginx и запрос для него
Подпишем сертификат нашей же собственной подписью
Чтобы nginx при перезагрузке не спрашивал пароль, сделаем для него беспарольную копию сертификата
Конфиг nginx
теперь сервер готов принимать запросы на https.
в переменных к бекенду появились переменные с информацией о сертификате, в первую очередь SSL_VERIFIED (принимает значение SUCCESS).
Однако если вы попытаетесь зайти на сайт, он выдаст ошибку:
Что ж, логично, в этом-то и вся соль!
Шаг 3. Создание клиентских сертификатов
3.1 Подготовка CA
Создадим конфиг
nano ca.config
со следующим содержимым:
Далее надо подготовить структуру каталогов и файлов, соответствующую описанной в конфигурационном файле
3.2. Создание клиентского закрытого ключа и запроса на сертификат (CSR)
Для создания подписанного клиентского сертификата предварительно необходимо создать запрос на сертификат, для его последующей подписи. Аргументы команды полностью аналогичны аргументам использовавшимся при создании самоподписанного доверенного сертификата, но отсутствует параметр -x509.
В результате выполнения команды появятся два файла client01.key и client01.csr.
3.3. Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).
При подписи запроса используются параметры заданные в файле ca.config
В результате выполнения команды появится файл клиентского сертификата client01.crt.
Для создания следующих сертификатов нужно повторять эти два шага.
3.4. Создание сертификата в формате PKCS#12 для браузера клиента
Это на тот случай, если к вашему серверу подключаются не бездушные машины, как в моём случае, а живые люди через браузер.
Запароленный файл PKCS#12 надо скормить браузеру, чтобы он смог посещать ваш сайт.
3.5 Подключение к полученному ssl cерверу с помощью curl
Использована опция -k, потому что сертификат в примере самоподписанный
Использованное ПО
Ubuntu Server 10.10 (Linux 2.6.35-22-server #35-Ubuntu SMP x86_64 GNU/Linux)
nginx 0.9.3
OpenSSL 0.9.8o 01 Jun 2010
Источник