Внедрение статуса сертификата OCSP в подпись PDF: не работает, когда OCSP responsederCert!= IsserCert
Чтобы подписать PDF, я использую signDetached.
...
OcspClient ocspClient = new OcspClientBouncyCastle();
MakeSignature.signDetached(appearance, digest, pks, chain, crlList, ocspClient, tsaClient, estimatedSize, subfilter);
PDF подписан без ошибок, но встроенный ответ OCSP отсутствует:
- Сервер OCSP работает нормально, но
- ЦС я использую знаки OCSP с доверенным ответным сертификатом (отличается от эмитента).
Как я могу заставить signDetached встраивать статус OCSP без проверки ответа OCSP (или передавать в signDetached responsederCert для доверия)?
более того
когда я пытаюсь проверить статус OCSP через com.itextpdf.text.pdf.security.OCSPVerifier, я получаю сообщение об ошибке:
Java::JavaSecurity::SignatureException: certificate does not verify with supplied key
В этом случае мы используем CA правительства Швейцарии:
Swiss Government Root CA I
`- Swiss Government Enhanced CA 01 < issuer certificate
`- Mor... < signature certificate
Ответы OCSP подписаны:
Swiss Government Root CA II
`- Swiss Government SSL CA 01
`- Swiss Government OCSP < OCSP responderCert
Корневые и промежуточные сертификаты доступны здесь:
- https://www.bit.admin.ch/adminpki/00247/00790/index.html?lang=de (SG Root CA I)
- https://www.bit.admin.ch/adminpki/00247/05329/index.html?lang=de (SG Root CA II)
1 ответ
... тем не менее, встроенный ответ OCSP отсутствует...
Изучив образец PDF, можно увидеть, что ответ OCSP встроен:
6469 3174: SEQUENCE {
6473 9: OBJECT IDENTIFIER '1 2 840 113583 1 1 8'
6484 3159: SET {
6488 3155: SEQUENCE {
6492 791: [0] {
6496 787: SEQUENCE {
6500 783: SEQUENCE {
.... CRL for CA certificate ....
: }
: }
: }
7287 2356: [1] {
7291 2352: SEQUENCE {
7295 2348: SEQUENCE {
7299 1: ENUMERATED 0
7302 2341: [0] {
7306 2337: SEQUENCE {
7310 9: OBJECT IDENTIFIER
: ocspBasic (1 3 6 1 5 5 7 48 1 1)
7321 2322: OCTET STRING, encapsulates {
7325 2318: SEQUENCE {
7329 270: SEQUENCE {
7333 97: [1] {
7335 95: SEQUENCE {
7337 11: SET {
7339 9: SEQUENCE {
7341 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
7346 2: PrintableString 'CH'
: }
: }
7350 29: SET {
7352 27: SEQUENCE {
7354 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
7359 20: UTF8String 'Swiss Government PKI'
: }
: }
7381 17: SET {
7383 15: SEQUENCE {
7385 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
7390 8: UTF8String 'Services'
: }
: }
7400 30: SET {
7402 28: SEQUENCE {
7404 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
7409 21: UTF8String 'Swiss Government OCSP'
: }
: }
: }
: }
.... remainder of OCSP response for signer certificate
: }
: }
: }
Таким образом, чтобы ответить на вопрос:
Как я могу заставить signDetached встраивать статус OCSP без проверки ответа OCSP (или передавать в signDetached responsederCert для доверия)?
Нет необходимости форсировать, iText встраивает полученный ответ OCSP без дальнейших проверок (быстрый просмотр кода поддерживает это).
Но неудивительно, что у вас возникли проблемы с этим правительством Швейцарии и его структурой сертификатов.
В соответствии с RFC 2560 (который явно указан в спецификации PDF ISO 32000-1 и, следовательно, должен использоваться здесь, несмотря на то, что RFC 6960 устарел):
Системы или приложения, которые полагаются на ответы OCSP... ДОЛЖНЫ отклонить ответ, если сертификат, необходимый для проверки подписи в ответе, не соответствует хотя бы одному из следующих критериев:
Соответствует локальной конфигурации органа подписи OCSP для соответствующего сертификата; или же
Является ли сертификат центра сертификации, выдавшего данный сертификат; или же
Включает значение id-ad-ocspSigning в расширение ExtendedKeyUsage и выдается центром сертификации, выпустившим соответствующий сертификат."
Для подписей правительства Швейцарии это означает:
- В общей среде у вас обычно нет конкретных локальных конфигураций для подписей правительства Швейцарии.
- Сертификат ответчика OCSP не является сертификатом, выдавшим сертификат подписавшего.
- Пока присутствует значение EKU, нет общего способа проверить, что сертификат OCSP и сертификат подписавшего были выданы тем же центром сертификации, поскольку их цепочки сертификатов не связаны.
Поэтому, как правило, эти ответы OCSP ДОЛЖНЫ быть отклонены.
И если вы посмотрите на более новый RFC 6960, вы увидите:
Примечание. Для обратной совместимости с RFC 2560 [RFC2560] не запрещено выпускать сертификат для авторизованного ответчика, использующего ключ выдачи, отличный от ключа, используемого для выдачи сертификата, проверяемого на отзыв. Однако такая практика настоятельно не рекомендуется, поскольку клиенты не обязаны распознавать ответчика с таким сертификатом в качестве авторизованного ответчика.
Таким образом, в настоящее время структура сертификата, используемая правительством Швейцарии, даже категорически не одобряется (что, по сути, означает, что IETF запретил бы ее, если бы им было позволено / разрешено).