Центр сертификации в собственной автономной системе

Мир не стоит на месте, на дворе 2026 год, интернет трещит по швам развивается, а вместе с ним развиваются и автономные системы, и если 20 лет назад писком моды был роутер с торрентокачалкой и внешний жесткий диск, то современный дом(не говоря уже про небольшой офис) может содержать множество очень интересных вещей:

• NAS (хранилище музыки, фильмов, фотографий и т.д.)

• DLNA (сервер потокового видео)

• GitLab (система контроля версий)

• Облачные решения для синхронизации файлов на устройствах

• Home Assistant (система управления умным домом)

• Записная книга (с разделяемым доступом)

• Сервер видеонаблюдения

• Собственный портал (например на WordPress)

И это далеко не всё. И самое главное — вам не надо оплачивать за каждый сервис ежемесячную подписку при лагающем интернете всё доступно и всегда под рукой. Но есть один маленький нюанс: очень стали популярны веб‑технологии, и бОльшая часть приложений — это веб‑приложения со всеми вытекающими отсюда последствиями.

Остаться в 2026 году на протоколе HTTP — это не современно, да к тому же у вас наверняка есть мобильник и вы используете WI‑FI (который вскрывается на ура, как это сделать вам подскажет даже Алиса), а значит, все ваши логины‑пароли рано или поздно станут общественным достоянием (уже стали это лишь вопрос времени). Потому использовать мы будем HTTPS, но и здесь нас ждет нюанс. Сертификация как и браузеры в последние годы активно развивались. И просто так взять какой‑то «левый» сертификат — уже не получится. Потому покупая роутер, NAS или настраивая какой‑либо софт всё чаще и чаще будете обнаруживать, что ваше устройство работает, а сертификат — не работает, так как современные браузеры имеют различные нейропротекторы и эвристическую защиту. Потому будем сертифицировать сами.

Разворачиваем свой Центр сертификации (ЦС). Лучший, на мой взгляд, вариант — использовать виртуальную машину(легко потерять бэкапить, переносить на другой комп и не давать злоумышленнику к ней доступ). Худший сценарий — развернуть ЦС прямо у себя на роутере. Я предпочитаю использовать OS без излишеств, потому мой выбор пал на Debian-13 в консольном исполнении. Создаем корневой ЦС и инициализируем PKI:

sudo apt install easy-rsamkdir ~/root-caln -s /usr/share/easy-rsa/* ~/root-ca/cd ~/root-ca./easyrsa init-pki 

Настраиваем vars (используя свой любимый редактор)

cp vars.example varsvim vars

Все параметры указанные выше необходимо раскомментировать. Рекомендую оставить RSA в последнем параметре, т.к. некоторый софт и железо по факту оказались неспособны переварить другие алгоритмы. Так же можно отредактировать длительность жизни сертификатов, но это всё уже индивидуально.

Строим ЦС

./easyrsa build-ca

Всё. Корень готов. Создаем промежуточный ЦС. Стоп. Зачем это нужно? На самом деле причины на то есть, и их далеко не одна:

• Можно разделить центры по сервисам (личные, гостевые, клиентские)

• Если у вас сеть друзей — каждый может иметь собственный ЦС (доверяйте друг другу и мир вам потом ответит тем же). Не стоит забывать, что TLS‑сертификаты — это про безопасность, а центры сертификации — это про доверие. Развивайте свой ЦС и люди начнут доверять вашему ЦС составите конкуренцию Let’s Encrypt.

• Проще администрировать сертификаты под одним корнем.

• Цепочка — это красиво!

Ещё раз создаем каталог и разворачиваем там промежуточный ЦС:

mkdir ~/services-caln -s /usr/share/easy-rsa/* ~/services-ca/cd ~/services-ca./easyrsa init-pki

Копируем туда для простоты vars из корневого ЦС, исправляем поля группы EASY_RSA_REQ_ на ещё более красивые.

./easyrsa build-ca subca

В pki/req будет запрос ca.req, переносим его в одноименный каталог корневого ЦС (командами утомлять не буду, всё равно никто их не будет вводить, когда существует mc). Далее заходим в корневой ЦС и подписываем

cd ~/root-ca./easyrsa sign-req ca ca 

Создаем цепочку (она нам понадобиться в некоторых случаях, когда софт не умеет брать корневой сертификат из хранилища ОС, но не имеет отдельных полей под корневой и промежуточный)

cat pki/issued/ca.crt pki/ca.crt > pki/intermediate-ca-chain.crt

Забираем сертификат ca.crt из issued кладем в /pki нового ЦС. Так же забираем ca.crt из /pki корневого центра (это наш корневой сертификат) и цепочку intermediate‑ca‑chain.crt — это наша альтернатива паре корня/intermediate (некоторый софт любит когда сертификаты разложены по полочкам, а другой — когда всё вместе, тут не угадаешь). На этом этапе наш Intermediate CA имеет собственный сертификат. Далее корневой ЦС нам уже не понадобится. Можно про него на некоторое время забыть.

Переходим в промежуточный ЦС (services-ca). Исправляем vars (можно переключить режим в cn_only, чтобы не загромождать клиентские и серверные сертификаты лишней информацией, либо обновить данные группы EASY_RSA_REQ_, так же можно настроить срок выдачи сертификата путем редактирования параметра EASYRSA_CERT_EXPIRE в днях).

Теперь с промежуточным ЦС можно делать всё что угодно: выпускать клиентские и серверные сертификаты, переносить на другую машину или подарить другу.

Теперь выпускаем серверные сертификаты. Какие они бывают? Если интересно — загляните в каталог x509-types. Мы будем выпускать серверный. Возвращаясь к реалиям 2026 года скажу, тут всё не так просто. Для защиты пользователей придуманы журналы выдачи (логи), списки отзывов (CRL) и средства проверки подлинности сертификатов (ocsp). Но вангую, что в ближайшие годы браузеры озвереют станут ещё лучше и будут браковать ваши сертификаты на ура. На момент написания статьи достаточно:

• установить корень и промежуточный ЦС в систему (в некоторых случаях и в браузер, например, Mozilla не доверяет вам и установленным вами на ваш же ПК сертификатам);

• прописать в сертификат корректное DNS-имя того сайта, для которого сертификат выпущен.

Покажу на примере своего synology NAS, как это делать. Создаю сертификат на сервисы, которые на нём развернуты (значительно сократил, чтобы не утомлять читателя их обилием).

./easyrsa gen-req syn.local nopass./easyrsa --subject-alt-name="DNS:audio.syn.local,DNS:cam.syn.local,DNS:mail.syn.local,DNS:test.syn.local" sign-req server syn.local

Забираем в issued наш сертификат (в private так же одноименный закрытый ключ), root и intermedate сертификаты у нас уже есть. Устанавливаем штатным образом его в synology. Root и intermediate сертификаты ставим в систему и любимые браузеры.

Проверяем. Яндекс-браузер.

Генерируем пару клиент/сервер для использования в ПО туннелирования:

#server./easyrsa gen-req kvn-gw.local nopass./easyrsa sign-req server kvn-gw.local#client./easyrsa gen-req notebook-1 nopass./easyrsa sign-req client notebook-1./easyrsa gen-req mobile-1 nopass./easyrsa sign-req client mobile-1

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

Желаю удачи в выпуске сертификатов и развитии автономных систем.