Найти в Дзене
Цифровая Переплавка

Создаём собственный центр сертификации (CA) в Linux: удобные самоподписанные сертификаты без предупреждений в браузере

Оглавление

Многие из нас, настраивая локальные веб-сервисы, сталкивались с надоедливыми предупреждениями браузеров о небезопасных соединениях. Да, «обычная» самоподписанная пара ключ/сертификат шифрует данные, но не устраивает браузеры, потому что не подписана «доверенным» центром сертификации (CA - Certificate Authority). К счастью, решить это можно, создав собственный удостоверяющий центр и добавив его в «белый список» доверенных CA в операционной системе и браузере. Расскажу, как сделать это изящно и избежать типичных проблем с OpenSSL — плюс немного личных наблюдений о безопасности.

Зачем заморачиваться с самоподписанным CA?

Ведь можно просто игнорировать «Not secure» — зачем усложнять жизнь? На самом деле, есть несколько причин, почему собственный CA полезен:

  • 💡 Разработка и тесты: При работе над проектом с HTTPS-соединениями на локальном (или тестовом) сервере хочется, чтобы всё вело себя, как на боевом сервере — без лишних ошибок в логах и без подозрительных предупреждений.
  • 🛡️ Защита от атак человека посередине (MITM - Man-in-the-Middle): Для личных нужд или закрытых корпоративных сетей часто важна надёжность: если сертификат доверенный и правильно подписан, риск перехвата снижается.
  • 🏷️ Удобство: Если постоянно игнорировать уведомления браузера, можно пропустить реальную угрозу. Когда всё настроено корректно, вы уверены, что любое предупреждение — это уже повод серьезно задуматься.

Основные шаги по созданию CA

Ниже я опишу примерную логику создания своего CA на базе OpenSSL, а затем расскажу, как «подарить» системе и браузеру уверенность в том, что они могут доверять именно этому корневому сертификату.

Генерируем корневой ключ и сертификат

Для начала создадим корневой ключ (private key) и корневой сертификат (self-signed) вашего CA:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out rootca.key
openssl req -x509 -key rootca.key -out rootca.crt -subj "/CN=localhost-ca/O=localhost-ca"

  • 🔑 rootca.key — это ваш секретный ключ (его надо беречь особо!)
  • 📄 rootca.crt — это «самоподписанный» корневой сертификат. Именно он определит «авторитетность» вашего CA.

Важно: В субжекте (-subj) можно указать любое имя организации. Здесь, например, используется localhost-ca, но вы вправе указать, что угодно.

Генерируем ключ и CSR для нового «рабочего» сертификата

  • 🔑 Создадим ключ для нашего будущего домена (пусть это будет localhost.key):
    openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out localhost.key
  • 📃 Далее формируем запрос на сертификат (CSR, Certificate Signing Request). Для этого часто удобно воспользоваться конфигурационным файлом csr.conf:
    [req]
    distinguished_name = dn
    prompt = no
    req_extensions = req_ext

    [dn]
    CN="localhost"

    [req_ext]
    subjectAltName = @alt_names

    [alt_names]
    DNS.0 = localhost

Тут мы явно указываем, что хотим сертификат на localhost, плюс при необходимости можем добавить другие домены (DNS.1, DNS.2 и т.д.).Создаём CSR:
openssl req -new -key localhost.key -out localhost.csr -config csr.conf

Подписываем сертификат корневым CA

Теперь осталось выдать «рабочий» сертификат, подписанный нашим корневым ключом:

openssl x509 -req -days 365 -extensions req_ext -extfile csr.conf \
-CA rootca.crt -CAkey rootca.key -in localhost.csr -out localhost.crt

  • 💾 localhost.crt — это итоговый подписанный сертификат для вашего домена, который теперь доверен вашим же CA.
  • Любое приложение, у которого есть rootca.crt (в качестве доверенного корневого сертификата), сможет проверить, что localhost.crt реально подписан именно вашим CA.

Доверяем CA системе и браузерам

Если вы запустите HTTPS-сервер (например, Nginx или Apache) с localhost.crt и localhost.key, то проверка будет «подвисать» на вопросе: «А знает ли система об этом CA?»

Установка CA в систему Linux

  • 🐧 Ubuntu

📂 Скопируйте ваш rootca.crt в /usr/local/share/ca-certificates/

🔃
Обновите список сертификатов:
sudo update-ca-certificates

Учтите, что Firefox и Chromium в некоторых версиях Ubuntu имеют свои собственные хранилища. Придётся добавить сертификат отдельно.

  • 🏴‍☠️ Arch Linux

Здесь всё даже проще:

sudo trust anchor rootca.crt

После этого Chromium и Firefox сразу воспользуются системным списком CA (что очень удобно).

Установка CA в браузерах

  • 🌐 FirefoxНастройки → «Приватность и защита»
    В разделе «Certificates» нажмите «View Certificates»
    Загрузите ваш rootca.crt во вкладку «Authorities»
    ✅ Отметьте все галочки доверия, нажмите «OK»
  • 🔒 Chromium (или Google Chrome)Настройки → «Конфиденциальность и безопасность» → «Безопасность» → «Управление сертификатами»
    Во вкладке «Authorities»
    импортируйте rootca.crt
    ✅ Также отметьте все требуемые галочки о доверии.

Теперь при заходе на https://localhost вы не увидите восклицательных значков и предупреждений — всё должно отображаться как надёжное соединение.

Личный взгляд на практику и безопасность

У меня был опыт развертывания подобной схемы для целой внутренней сети с десятками тестовых доменов. Когда все сертификаты подписаны одним CA, а этот CA «прописан» везде, работа становится проще и безопаснее:

  • 🔏 Частная сеть перестаёт генерировать гору предупреждений, разработчики и тестировщики более спокойны, а значит, пропадает соблазн «привыкнуть к красной плашке» и игнорировать настоящие угрозы.
  • 🧩 Унификация: не нужно настраивать «исключения» для каждого сервера, всё работает по единому стандарту SSL/TLS.
  • 🚧 Контроль: вам не приходится зависеть от внешних центров сертификации в несущественных проектах или же в условиях, где интернет вообще может быть ограничен.

Конечно, стоит помнить, что доверенный CA имеет полный «доступ к миру доверия». Если корневой ключ окажется скомпрометирован, придётся аннулировать всю цепочку. Потому хранить корневой rootca.key нужно максимально надёжно!

Источник