Аксенов Алексей
                                                             Февраль 2026
Free Gost CA

Этот УЦ предназначен для выпуска тестовых сертификатов по стандарту X509.
Интерфейс для выпуска реализован по стандарту REST API. 
Автоматическая документация сделана по стандартам Swagger.

Документация Swagger

Документация в HTML

Предыстория проекта

Презентация проекта

					

---

					
						
Что нового в версиях, начиная с 2026.02.04.0000:

   *  Исправлена ошибка сдвига времени на 3 часа дат начала и окончания запрошенного сертификта

   *  При запуске приложения, приложение пытается создать структуру базы данных если ее не было, либо мигрировать версию базы до самой последней

   *  Добавлены пробы (startup, liveness, readiness) для проверки состояния приложения

   *  Добавлены метрики производительности в формате OpenMetrics

   *  Добавлены примеры заполнения форм, в том числе и для форм с отправкой	файлов (TSP, OCSP)

Мотивация.

   *  Запуск новых экземпляров приложения стал намного быстрее из-за автоматического создания базы (ранее на ручное создание базы уходила пара часов)
   *  Было проведено нагрузочное тестирование и в нем очень не хватало внутренних метрик приложения чтобы понимать возможности нагрузки.
   *  Ранее чтобы проверить работу сервисов TSP и OCSP нужно было запускать сложные системы создания электронной подписи. Сейчас проверка идет через обычный сваггер


					

---

					
						
Что нового в версиях, начиная с 2025.11.23.0000:

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

Мотивация.

   *  Иногда после получения контейнера, хочется заглянуть в выданный сертификат, не устанавливая контейнер
   *  Для регистрации контейнера в Linux некоторые указывают внешний файл сертификата, который приходится извлекать из контейнера

					

---

					
						
Исправленные ошибки, начиная с 2025.04.27.0000:

   *  В серверных расширениях при указании critical: false само поле critical не должно попадать в сертификат, т.к. оно по умолчанию false

   *  Серийные номера сертификатов теперь соотвествуют стандарту RFC - являются положительными числами и уникальными в рамках каждого выдающего сертификата

Мотивация.

   *  Браузер "Chromium Gost" не отображает сведения о TLS сертификате, если у него внутри серверных расширений указаны поля critical: false
   *  "Инструменты Криптопро" и "КриптоАрм" создавают испорченные подписи, если серийный номер сертификата подписанта является отрицательным числом

Замечания к выпуску.

   Все ранее выданные сертификаты с отрицательными серийными номерами нужно просто прекратить использовать и перевыпустить новые. 
   Отзывать их не рекомендуется. 
   Определить "отрицательность" серийного номера можно таким образом - самый первый символ серийного номера должен быть цифрой меньше восьми.
   Например:
   *  e2cebedb05ad7a3915acdb14be1474eeb8a29517 - отрицательное число, первый символ "e"
   *  2a72893b4d4c999a1f702bee14db3616a2ffcfef - положительное число, первый символ "2", т.е. цифра меньше восьми


					

---

					
						
Что нового в версиях, начиная с 2025.03.10.0000:

   *  Добавлена поддержка следующих расширений:
      OCSPNoCheck
      CertificateTransparencyPoison
      DelegatedCredentials
      TLSFeature
      InhibitAnyPolicy
      CertificateTemplateName
      NetscapeBaseUrl
      NetscapeCaPolicyUrl
      NetscapeCaRevocationUrl
      NetscapeCertificateType
      NetscapeCertRenewalUrl
      NetscapeComment
      NetscapeRevocationUrl
      NetscapeSslServerName
      AppleApplicationIntegrationIntermediate
      AppleDeveloperIdApplication
      AppleDeveloperIdDate
      AppleDeveloperIdInstaller
      AppleSoftwareSigning

   *  Реализован новый шаблон сертификата с серверными расширениями

   *  Реализован метод конвертации в серверные шаблоны

   *  Реализован метод выпуска сертификатов по серверным шаблонам

Мотивация.

1. Я добрался до базы Certificate Transparency (https://certificate.transparency.dev/). Там лежит 12 миллиардов сертификатов со всего мира. Я смог прочитать пока всего 150 тысяч и нашел самые распространенные расширения, которые я не поддерживаю и решил их поддержать.
2. У меня состоялся спор с нашими коллегами на тему признаков квалифицированного сертификата. В приказе 795 на мой взгляд неясно описано серверное расширение AuthorityKeyIdentifier и моя реализация не удовлетворила коллег. Поэтому я решил отдать на их усмотрение правила формирования серверных расширений сертификата
3. Некоторые мои коллеги возжелали документацию :) Я начал процесс написания документации.

Замечания к выпуску.

Серверный шаблон сертификата можно отправлять в старый метод выпуска обычного сертификата - в этом случае серверная часть шаблона будет проигнорирована.
Полного бинарного соответствия расширений для сертификатов, выпущенных по сконвертированному шаблону не получится пока достичь. Конкретные примеры:
1. Расширение CertificateTemplateName (имя шаблона сертификата)
В стандарте описан тип строки как UTF8String но по результатам анализа тысяч сертификатов из CT оказалось что разные УЦ используют иногда BMPString. 
Когда мы конвертируем сертификат в шаблон, в шаблоне остается текст строки, но не сохраняется тип строки.
При выпуске сертификата по этому шаблону будет использован тип строки как в стандарте - UTF8String
2. Серверные расширения AuthorityInformationAccess, CRLDistributionPoints 
Значения этих расширений - списки. То есть расширения подразумевают множественные указания однотипных данных (например несколько разных мест хранения CRL или CRT)
При шаблонизации сертификата я добавляю в шаблон только первое место хранения и в результате выпуска сертификата, в нем будет одно место хранения