Выпуск и использование в Nginx самоподписанного TLS сертификата

Сейчас без HTTPS не хотят работать многие сервисы. А даже если и работают, то браузеры не дадут спокойно пользоваться. Поэтому приходится получать и настраивать сертификаты, даже если большой нужды в этом нет. Особенно если ты работаешь с ним один в локальной сети, либо вообще поднимаешь временно. Я обычно получаю сертификаты let's encrypt и копирую на нужный сервер, если к нему не проброшен доступ из интернета.

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

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

Будем выпускать сертификат для доменного имени zabbix.internal и IP адреса 172.30.245.222. Будет работать и так, и эдак.

Выпускаем ключ и сертификат для своего CA:

# mkdir ~/tls && cd ~/tls
# openssl ecparam -out myCA.key -name prime256v1 -genkey
# openssl req -x509 -new -nodes -key myCA.key -sha256 -days 9999 -out myCA.crt

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

# openssl genrsa -out zabbix.internal.key 2048
# openssl req -new -key zabbix.internal.key -out zabbix.internal.csr

Тут тоже зададут похожие вопросы. Отвечать можно всё, что угодно. Готовим конфигурационный файл:

# mcedit zabbix.internal.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 172.30.245.222
DNS.1 = zabbix.internal

Генерируем сертификат на его основе:

# openssl x509 -req -in zabbix.internal.csr -CA myCA.crt -CAkey myCA.key -CAcreateserial -out zabbix.internal.crt -days 9999 -sha256 -extfile zabbix.internal.ext

Копируем сертификат и ключ в директорию веб сервера:

# mkdir /etc/nginx/certs
# cp zabbix.internal.crt /etc/nginx/certs/.
# cp zabbix.internal.key /etc/nginx/certs/.

Создаём файл dhparam, который понадобится для конфигурации Nginx:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Добавляем в конфиг Nginx в целевом виртуальном хосте:

listen     443 http2 ssl;
server_name   zabbix.internal 172.30.245.222;
ssl_certificate /etc/nginx/certs/zabbix.internal.crt;
ssl_certificate_key /etc/nginx/certs/zabbix.internal.key;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Перезапускаем Nginx:

# nginx -t
# nginx -s reload

Передаём на свой компьютер файл myCA.crt и добавляем его в хранилище корневых доверенных центров сертификации. Настройка будет зависеть от операционной системы. Если нужно тут же, локально на сервере с Debian 12 настроить доверие этому CA, то делаем так:

# cp myCA.crt /usr/local/share/ca-certificates/.
# update-ca-certificates

Теперь можно браузером заходить по доменному имени или IP адресу, будет работать самоподписанный сертификат на 9999 дней без каких-либо предупреждений.

Сапоподписанный сертификат в Nginx

Получилась готовая инструкция для копипаста, которую можно сохранить и пользоваться.

Углубленный онлайн-курс по MikroTik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

8 комментариев

  1. Николай

    Приветствую.
    Делал по мануалу, чутка тупил, но вроде потом всё исправил) в итоге тестирую подключение через прокси nginx: curl https://ipecho.net/plain

    Выдаёт ошибку: curl: (56) CONNECT tunnel failed, response 404

    подскажете, с чем может быть связано?

    • Николай

      Если развернуто:

      ....

      < HTTP/1.1 404 Not Found
      < Server: nginx
      < Date: Thu, 21 Nov 2024 17:10:26 GMT
      < Content-Type: text/html
      < Content-Length: 146
      < Connection: keep-alive
      <
      * CONNECT tunnel failed, response 404
      * Closing connection 0
      * TLSv1.2 (OUT), TLS alert, close notify (256):
      curl: (56) CONNECT tunnel failed, response 404

    • Николай

      Вопрос отпал) Мануал рабочий на 100%, ошибка была в конфиге nginx, не относилась никак к ssl (ошибка в скрипте в proxy_auth.lua)

      Большое спасибо автору!

  2. Максим

    В google chrome и Safari работать не будет - не доверяют "самопалам" больше 397 дней. А так мануал отличный!

  3. mkcert hostaname.lan все....

  4. Аноним

    спасибо, годно

    • Спасибо, как всегда очень дельно. Вот эта строчка стремительно выходит из моды: listen 443 http2 ssl;
      Модно так:
      listen 443 ssl;
      http2 on;

      • Это да. Nginx вроде предупреждение уже выдаёт уже и на listen. Синтаксис меняется.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar