Перейти к содержанию

HOWTO: PKI trust anchors, OCSP/CRL — production deployment#

Эта инструкция описывает операционную процедуру для production-инсталляций Ruxeo: как контрибутить PKI trust anchors (root CA), OCSP-сервисы и CRL-точки в Sign module через Studio-package XML, а также как верифицировать deployment.

См. также DOCS/MECHANISMS/RU/SIGN_CORE.md §6.1+§6.2, DOCS/MECHANISMS/RU/SIGN_PROVIDERS.md §6.1, DOCS/MECHANISMS/RU/SIGN_LTARCH.md §6.1+§6.2 — все Resolved sansay373-iter5.

1. Архитектура#

1.1 Сервисы и extension points#

Sign module включает три EP-driven сервиса:

Сервис Component Extension points
RxsgnPkiValidationService pki-validation-service.xml trustAnchors, revocationServices, validationPolicies
RxsgnRevocationCheckService revocation-check-service.xml ocspServices, crlServices, revocationConfig
RxsgnRussianTrustStoreService russian-truststore-service.xml загрузка PEM из classpath / file path

С sansay373-iter5 все три компонента — в MANIFEST. EP активны и принимают contributions. Default contributions пустые — без deployment-уровня конфигурации валидация цепочки X.509 + OCSP/CRL не будет находить trust anchors и упадёт в branch «certificate chain not anchored».

1.2 Поведение при пустом registry#

  • validateCertificateChain(cert) — возвращает INVALID: no trust anchors; RxsgnSignServiceImpl.validateCryptoProSignature() пропускает в branch «valid если certificateValidTo > now()» (default-fallback, см. §2.4 SIGN_CORE.md). Это dev-режим, недопустим для production с УКЭП.
  • checkRevocation(cert) — возвращает UNKNOWN. CAdES-XL/A upgrade падает с «no OCSP responder available».

Production-deployment обязан контрибутить минимум один trustAnchor (russian-root-ca) и один ocspService или crlService.

2. Trust anchor (russian-root-ca)#

2.1 Получение PEM root CA#

Минцифры публикует аккредитованные корневые сертификаты в реестре УЦ. Для production-deployment с УКЭП трастуется минимум Минкомсвязь России Root CA (MINTSIFRY_ROOT_OID = 1.2.643.100.1).

Скачать PEM с актуального registry-снапшота, валидировать SHA-256 fingerprint руками против Минцифры, положить файл на инсталляцию:

sudo install -m 0644 russian-root-ca.pem /etc/ruxeo/pki/russian-root-ca.pem

2.2 Contribution через Studio package#

Создать в Studio-package файл pki-trust-anchors-contrib.xml:

<?xml version="1.0"?>
<component name="ru.ruxeo.deployment.pki.trust-anchors">

  <require>ru.ruxeo.sign.validation.PkiValidationService</require>

  <extension target="ru.ruxeo.sign.validation.PkiValidationService"
             point="trustAnchors">

    <trustAnchor id="russian-root-ca"
                 name="Минцифры России Root CA"
                 thumbprint="<SHA-256 fingerprint>"
                 subjectName="CN=Минкомсвязь России, O=Минкомсвязь России, C=RU"
                 algorithm="GOST R 34.10-2012-256"
                 russianRoot="true"
                 active="true" />

  </extension>

</component>

thumbprint сверять с тем что в e-trust.gosuslugi.ru. PEM-сам файл загружается через russian-truststore-service.xml (см. §4 ниже).

3. OCSP responder (Минцифры)#

3.1 Production endpoint#

Каждый аккредитованный УЦ публикует свой OCSP. Для подписей выданных УЦ Минцифры используется их собственный OCSP responder; URL берётся из поля AuthorityInfoAccess самого сертификата подписи — поэтому единого «Минцифры OCSP URL» нет.

Однако для каждого УЦ из реестра можно зарегистрировать fallback-сервис. Самый частый пример — КриптоПро тестовый OCSP (http://ocsp.cryptopro.ru) используется только в dev/CI; production требует подписания через УЦ заказчика и соответствующего OCSP.

3.2 Contribution#

<?xml version="1.0"?>
<component name="ru.ruxeo.deployment.pki.ocsp-services">

  <require>ru.ruxeo.sign.revocation.RevocationCheckService</require>

  <extension target="ru.ruxeo.sign.revocation.RevocationCheckService"
             point="ocspServices">

    <ocspService id="russian-root-ca-ocsp"
                 url="https://ocsp.example-uc.ru"
                 name="Аккредитованный УЦ — OCSP"
                 trustAnchor="russian-root-ca"
                 timeout="30000" />

  </extension>

  <extension target="ru.ruxeo.sign.revocation.RevocationCheckService"
             point="revocationConfig">

    <revocationConfig preferOcsp="true"
                     cacheTimeout="3600000"
                     connectionTimeout="10000"
                     readTimeout="30000"
                     maxRetries="3" />

  </extension>

</component>

preferOcsp=true — OCSP опрашивается первым, при недоступности — fallback на CRL (если контрибутирован). Подходит для LTArch upgrade (CAdES-XL/A).

4. CRL distribution point (fallback при недоступности OCSP)#

CRL — список отозванных сертификатов, периодически загружаемый. Дешевле чем OCSP при offline-валидации, но менее свежие данные.

<extension target="ru.ruxeo.sign.revocation.RevocationCheckService"
           point="crlServices">

  <crlService id="russian-root-ca-crl"
              url="http://crl.example-uc.ru/ca.crl"
              name="Аккредитованный УЦ — CRL"
              updateInterval="86400000"
              cacheEnabled="true" />

</extension>

updateInterval=86400000 (24 ч) — типовое значение. CRL кэшируется в JVM, рестарт инвалидирует кэш.

5. validationPolicy для 63-ФЗ УКЭП#

<extension target="ru.ruxeo.sign.validation.PkiValidationService"
           point="validationPolicies">

  <validationPolicy id="russian-law-63fz"
                   name="Russian Federal Law 63-FZ (УКЭП)"
                   requireGost="true"
                   requireQualified="true"
                   requireTimestamp="true"
                   policyOid="1.2.643.100.113.1" />

</extension>

requireGost=true — отсекает RSA/SHA-256 (RSP Mock provider). requireQualified=true — требует QUALIFIED_CERTIFICATE_OID (1.2.643.100.112). requireTimestamp=true — требует CAdES-T минимум (для УКЭП по 63-ФЗ).

6. Верификация после deployment#

После рестарта Nuxeo:

  1. MANIFEST/component activation — проверить логи на: 

    INFO  ru.ruxeo.sign.validation.PkiValidationService — Service started, ... trust anchors loaded
INFO  ru.ruxeo.sign.revocation.RevocationCheckService — Service started, ... OCSP services, ... CRL services loaded
    Цифры > 0. Если 0 — contribution не подхватился (проверить <require> и target).

  2. Diagnostics endpoint — Ruxeo.ExportDiagnostics operation (admin-only) возвращает JSON с блоком pki (см. §2.6 в SIGN_CORE.md, после планируемого расширения diagnostics — пока ручная проверка через JMX/getRegistry()).

  3. Smoke — подписать тестовый документ УКЭП-сертификатом, посмотреть в audit что signatureValidation.chainValidated=true, revocationStatus=GOOD.

Если chainValidated=false или revocationStatus=UNKNOWN после deployment — конфигурация не докручена.

7. Откат / отключение#

Не подписанные документы продолжают работать. Удалить Studio-package contribution-XML и рестартовать — Sign падает в dev-режим (см. §1.2), без блокировки запуска. Уже подписанные документы сохраняют подписи в storage; их валидация при следующем чтении упадёт в default-fallback (без chain validation) — не ломает чтение.

8. Связанные документы#