openSSL проверяет RFC 3161 TimeStampResp, подписанный самоподписанным сертификатом

Question

Я сгенерировал RFC 3161 TimeStampResp из RFC 3161 TimeStampReq, используя openSSL. Поэтому я использовал самоподписанный сертификат CA и сертификат TSA, выданный самоподписанным CA, с помощью этой команды:

openssl ts -reply -queryfile request.tsq -signer TSAcert.pem -out response.tsr

Ответ создан.

openssl ts -reply -text -in response.tsr

генерируется следующий вывод:

Информация о статусе:
Статус: предоставлено.
Описание статуса: не указано
Информация об ошибке: не указано
Информация о TST:
Версия: 1
OID политики: tsa_policy1
Алгоритм хеширования: sha256
Данные сообщения:
0000 - 43 2c bb 03 28 48 42 06-c0 c8 95 ee d8 32 9d 29 C,.. (HB...... 2.)
0010 - 09 7c 10 be 68 2a 77 f6-6e 96 61 7c bf 8f e2 cd. |..H *wna|....
Серийный номер: 0x01
Отметка времени: 1 августа 13:40:03 2018 по Гринвичу
Точность: 0x01 секунд, 0x01F4 миллис, 0x64 микро
Заказ: да
Nonce: не указано
TSA: DirName:/C= материал /ST=Some-State/L= материал /O= материал /CN= материал
Расширения:

Поскольку я пытаюсь проверить TimeStampResp против TimeStampReq, используя эту команду:

openssl ts -verify -queryfile request.tsq -in response.tsr -CAfile CAcert.pem -untrusted TSAcert.pem

Я получаю сообщение об ошибке, в котором говорится, что мой CA cert самоподписан (что на самом деле верно)

Подтверждение: не выполнено
139727615005120: ошибка:2F06D064: процедуры отметки времени:ts_verify_cert: ошибка проверки сертификата:../crypto/ts/ts_rsp_verify.c:182: ошибка проверки: самозаверяющий сертификат

Есть ли способ пропустить проверку сертификата или сказать openSSL, что этому CA можно доверять?

Answer 1

Во-первых, на самом деле это не вопрос программирования или разработки, и вместо этого probalby относится к superuser, unix.SX или, возможно, security.SX.

Во-вторых, это работает для меня (подтверждает, что все в порядке), если я реконструирую описанную вами ситуацию с "очевидными" значениями по умолчанию для информации, которую вы пропустили или отредактировали во всех последних выпусках (1.0.0-2,1.1.0). Все, что я могу предложить, это внимательно посмотреть, что именно в ваших сертификатах. Одна очевидная возможность: вы сделали имя TSA (cert Subject) таким же, как имя CA? Это делает цепочку неудачной, что приводит к типу ошибки проверки, которую вы получили.

В-третьих, в openssl ts -verify делать другие, чем обычная последовательность проверки. Но успешным TimeStampResp является SEQUENCE, содержащая sub-SEQUENCE, содержащую INTEGER 0, и CMS ContentInfo, содержащую SignedData с определенными ограничениями. Вы можете извлечь часть CMS SignedData - с openssl asn1parse -inform d чтобы найти его смещение, которое обычно составляет 9, а затем добавив -strparse 9 -out signedtst или просто что-то вроде tail -c +10 <tsresp >signedtst - тогда используйте

 openssl cms -verify -noverify -certfile signercert -inform der -in signedtst -binary -out tstinfo

(да -verify -noverify!) для проверки подписи на подписанных данных сертификатом (т. е. TSA), но не для проверки самого сертификата (в отношении цепочки, заканчивающейся в хранилище доверенных сертификатов, и необходимого ExtKeyUsage, а также OpenSSL -purpose timestampsign также ограничивает KeyUsage, хотя я не вижу этого в стандарте), а также извлекает подписанное тело, которое можно затем вручную проанализировать с помощью

openssl asn1parse -inform der -in tstinfo [-i]

хотя это не так удобно, как иметь маркировку и форматирование для вас.

ДОБАВЛЕНО: Есть некоторые добавленные опции в 1.1.0, которые я явно пропустил; см. /questions/2724368/proverka-tokena-vremennoj-metki-po-sertifikatu-no-ne-po-vsej-tsepochke-sertifikatsii-s-ispolzovaniem-openssl/2724373#2724373