OwnCA

Русский | English

Веб-панель удостоверяющего центра — замена самописным обвязкам вокруг EasyRSA и openssl ca. Делает то же самое: поднимает корневые и промежуточные УЦ, выпускает и отзывает сертификаты X.509, поддерживает CRL в актуальном состоянии, отдаёт ключи и сертификаты в PEM и PKCS#12 — только из браузера, а не из терминала.

Работает на штатном OpenSSL с RSA, ECDSA и Ed25519. Поддержка ГОСТ Р 34.10-2012 включается по желанию: с выключенным ГОСТ это обычный УЦ на неизменённом OpenSSL, без каких-либо engine'ов. Если нужна сертифицированная реализация, российскую криптографию можно перевести на CryptoPro CSP.

• Удостоверяющие центры. Корневые и подчинённые УЦ: генерация ключа и самоподписанного сертификата, подпись подчинённого родителем, импорт уже существующего УЦ (сертификат с закрытым ключом либо контейнер PKCS#12/PFX), чтобы продолжить подписывать им. Задаются алгоритм ключа, Subject DN, срок действия и длина пути (pathlen). Подчинённый УЦ создаётся в семействе ключей родителя — ГОСТ и RSA в одной цепочке не смешиваются.
• Выпуск сертификатов. Ключ либо генерируется на сервере, либо приходит с внешним запросом PKCS#10 — во втором случае содержимое сертификата и семейство ключа берутся из самого запроса, а не из полей формы. УЦ подписывает только сертификаты своего семейства ключей (gost / rsa / ec / ed25519), несовместимые сочетания отклоняются до выпуска. Для ГОСТ выбирается набор параметров.
• Профили расширений. Десять предустановленных (server, client, server_client, vpn, user, user_login, smartcard_logon, smime_sign, code_signing, timestamping) плюс любые свои: KU и EKU, basicConstraints, ограничения имён и политик, переопределение точек распространения, привязка OID-полей из реестра (DNS, IP, Email, URI, UPN, СНИЛС, ИНН, ОГРН, ОГРНИП и прочие). Без профиля доступен свободный режим с произвольными расширениями.
• Точки распространения. CRL, AIA (caIssuers и OCSP), SIA, freshestCRL и issuerAltName задаются на уровне УЦ и переопределяются профилем.
• Отзыв и CRL. Причина отзыва попадает в CRL как reasonCode. Список перевыпускается автоматически при каждом отзыве, вручную — по требованию, и разом для всех включённых УЦ в каталог раздачи.
• Перевыпуск сертификата с новым сроком и серийным номером из того же запроса и того же ключа; исходный сертификат остаётся неизменным.
• Выгрузка. Сертификат (.crt), закрытый ключ, запрос (.csr), PEM-файл «сертификат + ключ + цепочка», PKCS#12, а также сертификат УЦ и его CRL. Контейнер УЦ шифруется стандартным AES или набором ГОСТ (Кузнечик и Магма по ТК-26 либо устаревший ГОСТ 28147-89). Для ГОСТ-ключей доступен формат ТК-26 (.gost.p12) — PFX по RFC 9337 и RFC 9548 с выбором шифра Кузнечик или Магма.
• Режимы выпуска. Серверную генерацию ключа и отдельные семейства алгоритмов можно запретить — тогда соответствующие варианты исчезают из форм и отклоняются на сервере.
• Обслуживание. Версия openssl, состояние gost-engine, пересбор индекса метаданных с диска, перевыпуск всех CRL; на сборке с CryptoPro — состояние провайдера, лицензия и гамма ДСЧ.
• Два языка — русский (по умолчанию) и английский.

Работу с интерфейсом описывает встроенная контекстная справка: она открывается прямо из панели и всегда соответствует текущей странице. Посмотреть панель, ничего не устанавливая, можно в онлайн-демонстрации.

Стандартные алгоритмы работают на штатном OpenSSL из коробки. ГОСТ требует gost-engine и может быть выключен — тогда остаётся чистый УЦ на RSA / ECDSA / Ed25519.

• Электронная подпись: RSA (2048 / 4096), ECDSA (P-256, P-384), Ed25519; ГОСТ Р 34.10-2012 (256 / 512 бит) — опционально.
• Хеш-функции: SHA-256; ГОСТ Р 34.11-2012 — опционально.
• TLS фронтенда: обычные RSA/ECDHE-наборы, а при включённом ГОСТ — GOST2012-KUZNYECHIK-KUZNYECHIKOMAC и GOST2012-MAGMA-MAGMAOMAC.

Российскую криптографию можно обеспечивать сертифицированным CryptoPro CSP вместо свободного openssl + gost-engine. Тогда закрытый ключ рождается и живёт в контейнере провайдера: через CryptoPro идут генерация ключей, самоподпись корня, подпись подчинённых УЦ, выпуск конечных сертификатов (и при серверной генерации ключа, и по внешнему запросу PKCS#10), перевыпуск, выпуск CRL, экспорт PKCS#12 и импорт существующего ГОСТ-УЦ из PKCS#12/PFX. Остальные алгоритмы всегда остаются на openssl.

Включение двухуровневое: дистрибутив CryptoPro должен быть подан в сборку образа (в репозиторий он не входит), а затем провайдер включается на запуске переменной окружения. Команды сборки — в dev_env/README.md и demo/README.md.

Выбор криптопровайдера — на уровне отдельного УЦ, а не всей установки: он фиксируется при создании и больше не меняется. Поэтому в одной установке спокойно соседствуют УЦ на openssl и УЦ на CryptoPro; ранее созданные УЦ остаются на openssl, а подчинённый УЦ наследует провайдера родителя.

На сервере без графического интерфейса провайдеру нужна гамма ДСЧ — внешняя энтропия, которая расходуется при каждой генерации ключа. Её загружают через панель обслуживания; там же виден остаток и управляется лицензия (без своего серийного номера CryptoPro работает на встроенной демонстрационной лицензии сроком 90 дней). Сгенерировать тестовую гамму можно там же, но только для стенда — сертифицированная эксплуатация требует аппаратного источника.

Ограничения действуют только на ГОСТ-УЦ, созданные при включённом CryptoPro. Ни одно из них не срабатывает молча: несовместимое либо скрыто в интерфейсе, либо помечено заранее, либо даёт явную ошибку до начала операции.

1. Закрытый ключ неизвлекаем — в этом и смысл сертифицированного провайдера. Поэтому недоступны выгрузка ключа в PEM, PEM-файл «сертификат + ключ + цепочка» и импорт ГОСТ-УЦ парой PEM-файлов (нужен PKCS#12/PFX — тогда ключ попадает сразу в контейнер). Экспорт в PKCS#12 при этом работает.

2. Формат PKCS#12 — только нативный CryptoPro. Такой PFX корректно импортируется самим CryptoPro, но выбрать ТК-26 (.gost.p12) или ГОСТ-наборы шифрования контейнера нельзя: платформа не даёт управлять этим параметром. В панели такие варианты для CryptoPro-УЦ не предлагаются, подмена формата не выполняется.

3. Набор расширений X.509 закрыт.

Профиль с чем-либо из правой колонки помечается в редакторе профилей и в форме выпуска — оператор видит несовместимость до заполнения формы, а не после отправки.

Всё остальное работает наравне с openssl: наборы параметров ГОСТ, csr.pem при серверной генерации ключа, reasonCode в CRL, срок действия CRL, флаги SKI/AKI из профиля.

• Одна учётная запись администратора, задаваемая переменными окружения. Ролей, разграничения прав и журнала действий по пользователям нет.
• Только веб-интерфейс. Протоколов автоматизации (ACME, SCEP, EST, CMP) и внешнего API выпуска нет.
• OCSP-респондера нет. Поля AIA/OCSP лишь записывают URL в сертификат; отвечать по нему должен внешний сервис. Штатная проверка отзыва — по CRL.
• CRL обновляется по событию, а не по расписанию — при отзыве и по кнопке. Планировщика и уведомлений об истечении сертификатов нет; на дашборде показывается лишь список тех, у кого срок подходит к концу.
• Аппаратные носители и HSM (PKCS#11) не поддерживаются. Сертифицированный вариант хранения ключа — только программный контейнер CryptoPro CSP.
• Хранилище — локальный каталог одного экземпляра. Кластеризация и репликация не предусмотрены; PostgreSQL хранит только индекс метаданных, а первоисточник — файлы на диске.
• Готовые окружения в репозитории — стендовые. Панель в них запускается dev-сервером Django с самоподписанным TLS и паролем admin по умолчанию. Для эксплуатации нужны свой WSGI-сервер, собственный DJANGO_SECRET_KEY, настоящие сертификаты фронтенда и смена учётных данных.
• Резервное копирование. У openssl-УЦ ключи лежат в каталоге хранилища вместе с сертификатами, а у CryptoPro-УЦ — в контейнерах провайдера, отдельно. Копировать нужно оба тома и согласованно: восстановленный из одного лишь хранилища CryptoPro-УЦ не сможет ничего подписать. Точный перечень томов — в README окружений.
• ГОСТ на gost-engine — свободная, не сертифицированная реализация. Если требуется сертифицированная криптография, нужен криптопровайдер CryptoPro CSP с описанными выше ограничениями.

Два готовых сценария Docker Compose:

• dev_env/ — сборка из исходников, код монтируется в контейнер, live-reload. Для разработки и отладки. См. dev_env/README.md.
• demo/ — предсобранные образы; стек переносится на изолированный хост одним архивом. См. demo/README.md.

GNU General Public License v3.0 — см. LICENSE.