Аксенов Алексей
Апрель 2025
Free Gost CA
Этот УЦ предназначен для выпуска тестовых сертификатов по стандарту X509.
Интерфейс для выпуска реализован по стандарту REST API.
Автоматическая документация сделана по стандартам Swagger.
Документация Swagger
Документация в HTML
Предыстория проекта
Презентация проекта
Исправленные ошибки, начиная с 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)
При шаблонизации сертификата я добавляю в шаблон только первое место хранения и в результате выпуска сертификата, в нем будет одно место хранения