OpenSSL の署名プロセスから .tsr 応答を受け取りました。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
ローカル発行者証明書とは何ですか? 「ts」コマンドで -noverify を使用できません。
答え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基本的に 4 つの部分で構成されます。
トークン本体の署名をチェックし、(主張された)署名者の証明書の公開鍵を使用して検証し、RFC3161 によって課せられたその他の制約が満たされていることを確認します (SignerInfo は 1 つだけであり、ESSCertId を含む signedAttrs を使用する必要があります)。署名者の証明書がタイムスタンプ応答に含まれているかどうかは、RFC3161 要求のフラグによって制御されます。含まれていない場合、検証者/信頼者は既に証明書を持っているか、他の方法で取得する必要があります。
要求された署名者の証明書を少なくとも1つの信頼できるCAにリンクするチェーン（パスとも呼ばれる）を構築します。これは、通常、信頼ストアに存在することでローカルに信頼できると定義されているルート証明書またはアンカー証明書と呼ばれるCA証明書によって表されます。RFC3161の応答5月チェーン証明書を含める必要がありますが、必須ではありません。含めない場合は、検証者/信頼者がすでにチェーン証明書を持っているか、他の方法でチェーン証明書を取得する必要があります。
各証明書の署名が次の上位の証明書（つまり親）の公開鍵で検証されていること、各証明書が署名時点で有効であること（有効であり期限切れではないこと）、および各証明書のその他のフィールドがチェーン内での使用に適切であることを確認することで、チェーンを検証します。詳細については、RFC5280 秒 6. 検証すべきチェーン内の各証明書が（署名時点で）失効していないことを確認することが含まれますが、OpenSSL はデフォルトではこの部分を実行しません。失効チェックのさまざまなバリエーションを実行するためのオプションがいくつかありますが、そのいずれも使用しませんでした。
最後に、証明書（チェーン）がここでの目的、つまりタイムスタンプに適しているかどうかを確認します。SSL/TLSやS/MIMEなどの証明書の使用の場合、通常、証明書が信頼できるCAの権限の下で正当に発行されただけでなく、発行されたことを確認する必要があります。に特定のエンティティ（ウェブサイト、メールサーバー、または確実に識別された人物）ですが、タイムスタンプでは通常気にしませんどれのTSAはトークンを発行したが、いくつかの有効な TSA が実行したため、この最後のチェックでは、証明書/チェーンの ExtendedKeyUsage にタイムスタンプ (の標準化された OID が含まれているため許可されている) が含まれていることのみが検証されます。
これらを総合すると（そして総合的に判断すると）、私たちが持っているデータは実際に有効な TSA によって発行されたタイムスタンプ トークンであり、意図的または偶発的に偽造または変更されておらず、信頼できるものであることが証明されます。
OpenSSLコマンドラインの場合、ルート/アンカーは、指定されたCAfile-CAfileおよび/または-CApathデフォルトのCAfileおよび/またはCApath（存在する場合）のいずれかで構成されるトラストストアに存在しなければなりません。いずれの場合もPEM形式です。また、（マニュアルページはあまり明確ではありませんが）応答メッセージに含まれていないその他のチェーン証明書は、どちらかトラストストアまたは指定されたファイル-untrusted（単一のファイルである必要がありますが、PEM 形式の複数の証明書を含めることができます）に存在する必要があります。デフォルトでは、ルート証明書のみがチェーン/パス アンカーとして受け入れられます（歴史的にはルートのみでした）。ただし、-partial_chain1.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親が1人判明しているSectigo RSA Time Stamping CA https://crt.sh/?id=1437089092発行者は ですUSERTrust RSA Certification Authority。そのCAには4つの証明書（潜在的な親）がリストされています。https://crt.sh/?caid=1167-- そのうちの1つはMicrosoft codesigningで、通常はタイムスタンプがMicrosoft Authenticodeコード署名の場合にのみ使用されます。他の3つは一般的な使用に適していますが、Comodoという名前のものだけは比較的新しいものです（発行はわずか3か月前です）。参考までに、id=1437089092のAIAは、http://crt.usertrust.com/USERTrustRSAAddTrustCA.crtAddTrustルートから証明書を提供するhttps://crt.sh/?id=4860286これは最も古いものです（2000 年に発行され、1 年以内に期限が切れます）。
メッセージ内の証明書を使用して、使用したいルートまたはアンカーに必要な追加のチェーン証明書とアンカー証明書を判別し、 または-CAfileで使用する可能性のある別のファイルで提供されている証明書と比較します-untrusted。