Библиотека jsrsasign предоставляет инструменты для работы с X.509
сертификатами, однако её возможности при работе с цепочками сертификатов
(certificate chains) ограничены по сравнению с полноценными
криптографическими стеками вроде OpenSSL или встроенных средств
браузеров.
Цепочка сертификатов представляет собой последовательность
сертификатов, где каждый последующий сертификат подписан предыдущим,
заканчиваясь доверенным корневым центром сертификации (Root CA). В
jsrsasign отсутствует встроенный механизм автоматической валидации такой
цепочки как единого объекта.
Отсутствие полной
автоматической валидации
В jsrsasign нет функции, которая принимает массив сертификатов и
полностью проверяет:
- корректность подписей между звеньями цепочки
- наличие доверенного корневого сертификата
- корректность порядка сертификатов
- отсутствие пропущенных промежуточных CA
Проверка должна выполняться вручную:
- Разбор каждого сертификата
- Извлечение публичного ключа издателя
- Проверка подписи следующего сертификата
- Повторение для всей цепочки
Это усложняет код и увеличивает вероятность ошибок.
Ограниченная работа с trust
store
Библиотека не содержит встроенного хранилища доверенных корневых
сертификатов (trust store):
- отсутствуют предустановленные корневые CA
- нет механизма обновления списка доверенных центров
- нет API для автоматического сопоставления цепочки с доверенным
якорем
Вся логика доверия должна реализовываться вручную:
- загрузка root-сертификатов
- хранение списка доверенных ключей
- проверка совпадения Subject/Issuer
Нет поддержки
автоматического построения цепочки
Если передан только конечный сертификат (end-entity), jsrsasign:
- не умеет автоматически находить промежуточные сертификаты
- не извлекает ссылки на CA Issuers из расширений
- не выполняет загрузку сертификатов по URL
В результате:
- цепочка должна быть заранее полностью известна
- порядок сертификатов должен быть корректно задан вручную
Ограничения при проверке
расширений
Хотя jsrsasign позволяет читать расширения X.509, она не выполняет
полноценную интерпретацию некоторых критических полей цепочки:
Basic Constraints
- не проверяется автоматически флаг
CA:TRUE
- отсутствует контроль допустимой глубины цепочки
(pathLenConstraint)
Key Usage
- не гарантируется, что сертификат CA имеет право подписи
(
keyCertSign)
Extended Key Usage
- не учитывается назначение сертификата (например, TLS, code
signing)
Все эти проверки необходимо реализовывать вручную.
Отсутствие проверки
отзыва сертификатов
jsrsasign не реализует встроенные механизмы проверки отзыва:
- нет поддержки CRL (Certificate Revocation List)
- нет встроенной проверки OCSP (Online Certificate Status
Protocol)
Хотя библиотека содержит базовые классы для CRL и OCSP,
отсутствует:
- автоматическая интеграция в процесс валидации
- загрузка CRL/OCSP по URL
- проверка актуальности данных
Это делает невозможной полноценную проверку статуса сертификатов без
внешней логики.
Нет
проверки времени для всей цепочки как единого объекта
Проверка сроков действия (notBefore,
notAfter) выполняется:
- только для конкретного сертификата
- без учёта всей цепочки
Отсутствует:
- проверка, что все сертификаты были действительны в один и тот же
момент времени
- возможность указания «времени проверки» (validation time) для всей
цепочки
Проблемы с порядком
сертификатов
jsrsasign не нормализует цепочку:
- не сортирует сертификаты автоматически
- не проверяет корректную последовательность
Ошибки порядка могут привести к:
- некорректной проверке подписей
- ложным отрицательным результатам
Отсутствие
поддержки AIA и загрузки промежуточных CA
Расширение Authority Information Access (AIA) содержит ссылки на
промежуточные сертификаты, однако:
- jsrsasign не использует эти ссылки
- не выполняет HTTP-запросы для загрузки CA
- не дополняет цепочку автоматически
Это особенно критично при работе с реальными TLS-сертификатами, где
промежуточные CA часто не передаются явно.
Ограничения в
производительности
При ручной проверке цепочки:
- каждый сертификат парсится отдельно
- криптографические операции выполняются последовательно
- отсутствует кэширование результатов
Это приводит к:
- росту времени проверки при длинных цепочках
- увеличению нагрузки в браузере
Ограничения в среде браузера
В браузере:
- нет доступа к системному trust store
- отсутствуют нативные API для полной проверки цепочек
- невозможно использовать системные механизмы валидации
jsrsasign в этом случае остаётся единственным инструментом, но:
- вся логика доверия должна быть реализована вручную
- безопасность полностью зависит от корректности реализации
Отсутствие строгой
политики обработки ошибок
Библиотека:
- не всегда выбрасывает исключения при некорректной цепочке
- может возвращать частичные результаты
- не различает типы ошибок (подпись, срок, доверие)
Это усложняет диагностику и обработку ошибок.
Ограниченная
поддержка современных стандартов
Некоторые современные аспекты PKI не реализованы полностью:
- сложные политики сертификации (Certificate Policies)
- name constraints
- cross-certification
- сложные сценарии PKI
jsrsasign ориентирована на базовые сценарии, а не на полноценную
инфраструктуру доверия.
Практические последствия
При использовании jsrsasign для проверки цепочек сертификатов:
- требуется ручная реализация большинства этапов валидации
- повышается риск ошибок безопасности
- невозможно полностью воспроизвести поведение TLS-стека браузера
- сложнее соответствовать стандартам X.509 и RFC 5280
Типичная стратегия обхода
ограничений
На практике применяются следующие подходы:
предварительная проверка цепочки на сервере (например, через
OpenSSL)
передача уже валидированной цепочки в клиент
использование jsrsasign только для локальных криптографических
операций
ручная реализация минимального набора проверок:
- подписи
- сроков действия
- базовых ограничений
Ключевые ограничения в
краткой форме
- нет полной автоматической валидации цепочки
- отсутствует trust store
- нет проверки отзыва (CRL/OCSP)
- не строится цепочка автоматически
- отсутствует строгая проверка расширений
- нет поддержки AIA
- требуется ручная реализация логики доверия
Глубокое понимание этих ограничений критично при использовании
jsrsasign в системах, где требуется высокая степень криптографической
надёжности и соответствие стандартам PKI.