☰

Странная проблема с проверкой OpenSSL TS

tag-icon • tag-icon openssl
Странная проблема с проверкой OpenSSL TS

У меня есть ответ .tsr от процесса подписания в OpenSSL. openssl ts -replyработает.

openssl ts -reply -in b1.tsr -text

Using configuration from g:/progs/openssl/ssl/openssl.cnf                                                                     
Status info:                                                                                                                  
Status: Granted.                                                                                                              
Status description: unspecified                                                                                               
Failure info: unspecified                                                                                                     

TST info:                                                                                                                     
Version: 1                                                                                                                    
Policy OID: 1.3.6.1.4.1.6449.2.1.1                                                                                            
Hash Algorithm: sha256                                                                                                        
Message data:                                                                                                                 
    0000 - 10 20 96 d8 03 ec ed 6e-03 56 3d d6 d6 a7 14 50   . .....n.V=....P                                                 
    0010 - b0 a7 53 a9 34 4e b9 57-f7 e2 83 13 5e 0d df e0   ..S.4N.W....^...                                                 
Serial number: 0xA7ADC6135D0A39500F7C3B0C41578D8C2CB62B87                                                                     
Time stamp: Jun 22 10:59:44 2019 GMT                                                                                          
Accuracy: unspecified                                                                                                         
Ordering: no                                                                                                                  
Nonce: 0xD4154ECA4E9A0D06                                                                                                     
TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Time Stamping Signer #1                   
Extensions:

openssl ts -verifyтерпит неудачу.

openssl ts -verify -sha256 -digest "102096d803eced6e03563dd6d6a71450b0a753a9344eb957f7e283135e0ddfe0" -in b1.tsr -CAfile comodo.pem
Verification: FAILED
11928:error:2F06D064:time stamp routines:TS_VERIFY_CERT:certificate verify error:.\crypto\ts\ts_rsp_verify.c:264:Verify error:unable to get local issuer certificate

Что это за локальный сертификат издателя? Я не могу использовать -noverify в команде "ts".

решение1

Чтобы построить полную цепочку сертификатов для проверки OpenSSL, вам понадобится не только корневой сертификат (который вы указали с помощью переключателя -CAfile), но и сертификат, который использовался для подписи TSResponse.

Из страницы руководства ts:

-untrusted cert_file.pem
           Set of additional untrusted certificates in PEM format which may be needed when building the certificate chain for the TSA's signing certificate. This
           file must contain the TSA signing certificate and all intermediate CA certificates unless the response includes them.  (Optional)

решение2

Ошибка проверки «невозможно получить локальный сертификат издателя» означает, что OpenSSL не удалось найти в локальном хранилище доверенных сертификатов ни полный корень цепочки (или якорь), ни следующее звено неполной цепочки, которое может быть, а может и не быть корнем/якорем.

В качестве справки, поскольку вы не указали, насколько вы понимаете проверку на основе сертификатов, она ts -verifyв основном состоит из четырех частей:

  • проверка подписи в теле токена, проверка с использованием открытого ключа в сертификате (заявленного) подписчика, а также некоторые другие ограничения, налагаемые RFC3161, соблюдены (должен быть только один SignerInfo, и он должен использовать signedAttrs, включая ESSCertId). Включение сертификата подписчика в ответ с временной меткой контролируется флагом в запросе RFC3161; если он не включен, проверяющий/проверяющий должен уже иметь его или получить его другими способами.

  • построить цепочку (также называемую путем), которая связывает сертификат заявленного подписчика по крайней мере с одним доверенным CA, представленным сертификатом CA, называемым корневым или якорным сертификатом, который локально определяется как доверенный, как правило, по наличию в хранилище доверенных сертификатов. Ответ RFC3161можетвключают сертификат(ы) цепочки, но это не обязательно; в противном случае проверяющая/проверяющая сторона должна иметь их уже или получить их другими способами.

  • проверить цепочку, проверив, что подпись каждого сертификата соответствует открытому ключу следующего сертификата более высокого уровня (т. е. родительского), что каждый сертификат действителен (действует и не просрочен) на момент подписания, а также что ряд других полей в каждом сертификате подходят для его использования в цепочке; подробности см. вRFC5280 раздел 6. Проверкадолженвключить проверку того, что каждый сертификат в цепочке не отозван (на момент подписания), но OpenSSL не выполняет эту часть по умолчанию; существует несколько вариантов проверки отзыва, но вы не использовали ни один из них.

  • наконец, проверьте, что сертификат (цепочка) подходит для этой цели, а именно для временной метки. Для других случаев использования сертификата, таких как SSL/TLS и S/MIME, нам обычно нужно проверить не только то, что сертификат был законно выпущен под руководством доверенного центра сертификации, но и то, что он был выпущенкконкретная сущность (веб-сайт, почтовый сервер или человек, который был надежно идентифицирован). Однако для временной метки мы обычно не заботимсякоторыйTSA выпустила токен, только этотнекоторыйДействительный TSA это сделал, поэтому последняя проверка только подтверждает, что ExtendedKeyUsage сертификата/цепочки включает (стандартизированный OID для и, таким образом, разрешает) отметку времени.

В совокупности (и только в совокупности) все это подтверждает, что имеющиеся у нас данные на самом деле являются маркером временной метки, выпущенным действительным TSA, и не были подделаны или изменены ни намеренно, ни непреднамеренно, и, следовательно, им можно доверять.

Для командной строки OpenSSL корень/якорь должен находиться в используемом хранилище доверенных сертификатов, которое состоит либо из указанного -CAfileи/или -CApathCAfile по умолчанию и/или CApath, если они существуют, в любом случае в формате PEM; и (хотя страница руководства не очень понятна) любые другие сертификаты цепочки, отсутствующие в ответном сообщении, должныилинаходиться в хранилище доверенных сертификатов или в файле, предоставленном как -untrusted(который должен быть одним файлом, но может содержать несколько сертификатов в формате PEM). По умолчанию только корневой сертификат принимается (и исторически только корневой) в качестве привязки к цепочке/пути, но с опцией, -partial_chainначиная с версии 1.0.2, принимается некорневая привязка к цепочке/пути.

Дисплей ts -reply -textне показывает уровень CMS и, в частности, какой сертификат(ы) в нем предоставлен(ы). Вы можете увидеть все, asn1parse -inform der [-i]но должны расшифровать вручную. Более удобно, вы можете извлечь часть CMS SignedData, также известную как подписанный токен, согласномой ответ здесьа затем проверьте сертификаты следующим образом:

 openssl ts -reply -in respfile -token_out -out tokenfile
 openssl pkcs7 -inform der -in tokenfile -print_certs 
 # if desired/necessary, feed any or each of the PEM cert block(s) 
 # to openssl x509 -text -noout to get full details

У меня нет опыта работы с этим TSA, но исходя из принципа, что сертификат и цепочка известного публичного TSA должны быть публично зарегистрированы, единственный зарегистрированный сертификат с такой темой, известный crt.sh (который также управляется Comodo-now-Sectigo), этоhttps://crt.sh/?id=1437463789который имеет одного известного родителяSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092чей эмитент USERTrust RSA Certification Authority; этот CA имеет четыре сертификата (потенциальных родительских), перечисленных наhttps://crt.sh/?caid=1167-- один из них Microsoft codesigning, который обычно используется только если временная метка относится к подписи кода Microsoft Authenticode, а три других все приемлемы для общего использования, хотя единственный, названный Comodo, довольно новый (выпущен всего 3 месяца назад). Кстати, AIA в id=1437089092 указывает наhttp://crt.usertrust.com/USERTrustRSAAddTrustCA.crtкоторый обслуживает сертификат из корня AddTrusthttps://crt.sh/?id=4860286который является самым старым (выпущен в 2000 году и истекает в течение года).

Используйте сертификат(ы) в сообщении, чтобы определить, какие дополнительные сертификаты цепочки и якоря необходимы для корня или якоря, которые вы хотите использовать, и сравните с тем, что указано в вашем -CAfileили другом файле, который вы можете использовать с -untrusted.

Связанный контент