X.509証明書を1つのバンドルで転送する必要がある場合は、通常、それらをPKCS#7にパックすることをお勧めします。また、PKCS#7のコンテンツに署名できます。
OpenSSLでは、次の方法でPKCS#7に証明書をパックできます。
openssl crl2pkcs7 -nocrl -certfile domain.crt -certfile ca-chain.crt -out domain.p7b
「openssl crl2pkcs7」のマニュアルページから理解できるように、このPKCS#7は署名されています。
出力ファイルは、署名者を含まず、ただ含むPKCS#7の署名されたデータ構造です証明書とオプションのCRL
ここでいくつかの質問:
全体的な概念を間違って理解している場合は、それを明確にしてください。
TLDR:実際には署名されていません。間違って理解しています。説明するために、最初から始めましょう。
PKCS#7、およびそのわずかに変更および拡張されたIETFized [1]フォームCMS暗号メッセージ構文 http://tools.ietf.org/html/rfc3852 et pred et amiciは、さまざまな暗号化機能に関する一連の異なるが類似したメッセージ。 PKCS#7/CMSの1つのタイプメッセージが呼び出されますSignedDataそして、その当初の目的は、ご想像のとおり、デジタル署名または一般的な目的でデータを伝達することです ormore 署名、たとえば両当事者が署名した契約。 PKCS#7は(主に)公開鍵暗号方式を使用しており、PKI公開鍵内部構造と呼ばれる、人や組織やシステムなどのエンティティに公開鍵の値を適切に照合する方法を必要としています。実際には、使用するPKIはX.509 CertificatesCAs Certificate Authoritiesによって発行され、これはCRLs Certificate Revocation Listsを使用して不正な証明書を取り消すことができます(そして今日OCSPも使用していますが、これはPKCS#7の後で行われました。
SignedDataは実際には3つの主要な部分で構成されています。ContentInfoという名前の構造内の実際のデータ。可変数のSignerInfo構造には、それぞれ1つの署名と、署名の検証に必要な公開鍵を含む証明書のIDを含むいくつかのメタデータが含まれます。変数番号(多分なし)証明書および/またはCRL受信者が(署名)公開鍵を決定および検証する必要がある場合があるまたは任意の目的で。一般的に、SignerInfoの数、つまり署名はゼロになる場合があります。その場合、データは役に立たないため省略されます。
したがって、データなし、「署名者なし」(ゼロのSignerInfo構造)、証明書および/またはCRLのみのSignedDataは、いくつかの関連する証明書を含む標準化された形式を提供します。 CRL。これについて他に適切な標準化された方法がなかった初期の頃。その結果、広く採用され、ユビキタスになりました。この形式は、通常、「p7b」および「p7c」という拡張子で識別されます。 X.509とPKCS#7証明書の違いは何ですか? を参照してください。
質問に関して:この形式は、SignedDataという名前のタイプのPKCS#7またはCMS構造ですが、実際にはデータまたはそのデータの署名は含まれていません。証明書と/またはCRL。署名されていないため、それ自体を確認することはできません。
各証明書またはCRL自体はで署名されており、一般的なデータ署名ではなく、cert/CRL形式に固有の署名を使用しています。これは、それがp7b内にあるのか別のものにあるのかには依存しません。証明書の抽出後の各(非ルート)証明書またはCRLは、証明書の「上」に有効な証明書チェーンがあり、それを何かに使用する場合に検証できます。ただし、すべてのPKI署名は、信頼された「ルート」または「アンカー」(Verisign、GoDaddyなど)の(通常は小さい)セットから、他のエンティティ(HTTPSまたは他のSSL /ネット上のTLSサーバー、世界中の電子メール送信者、世界中のプログラム開発者など)。最終的に、信頼するアンカーを決定するか、その決定を誰かに委任します(Windowsの場合はMicrosoft、Javaの場合はOracle、Firefoxの場合はMozillaなど)。
OpenSSLでは、証明書および(オプションで)CRLを使用するすべての(AFAICS)操作で、選択またはデフォルト設定できるCA(ルート)証明書のトラストストアに対してそれらを検証します。コマンドラインverify
ユーティリティを使用して、証明書を手動で(再)検証することもできます。 https://www.openssl.org/docs/apps/verify.html を参照してください。他のツールやプログラムでも同等の処理が行われますが、詳細は一部異なります。
[1]比較のために、NetscapeプロトコルのSSL Secure Sockets LayerはIETFに引き継がれ、わずかに変更および拡張され、TLS Transport Layer Securityに名前が変更されました。時々問題となる技術的な違いがありますが(SSLに影響を与える最近のPOODLEの脆弱性のように、少なくとも正しい実装ではTLSで修正されています)、SSLとTLSの大部分は機能的に同じであり、人々はしばしばSSLを意味するとだけ言います両方とも。同様に、PKCS#7とCMSは非常に似ているため、多くの人が両方にどちらかの名前を使用しています。
コメントごとに2/06更新: valid チェーンを受信者に送信した場合、最も低い(リーフ)証明書を正しく検証するを使用するそのチェーン。受け取ったチェーンが有効かどうかを証明します。
PKCS#7/CMSはネストできます。これは一般的に署名と暗号化(別名エンベロープ)の両方に使用されますが、他の組み合わせも可能です。受信者が有効なチェーンだけでなく、送信する正確なチェーン(または他のセット)を取得することに本当に関心がある場合は、2番目の外側のSignedDataメッセージのコンテンツとしてp7bを置くことができます。この場合、別の選択肢があります。主に歴史的な理由により、PKCS#7/CMSは「切り離された」署名を生成できます。この場合、SignedDataオブジェクトには実際にはデータが含まれず、SignerInfo(s)とハッシュアルゴリズムのようないくつかのメタデータのみが含まれます( s);この場合、受信者が確実に接続できるように、両方のデータチャンクを送信する必要があります。 Message12345.datおよびMessage12345.sig。または、SignedDataメッセージのコンテンツスロットにデータを「埋め込む」こともできます。これはおそらくあなたの場合にはもっと簡単です。 OpenSSLコマンドラインは、2つのステップを実行するだけでこれを実行できます。多くのメールソフトウェアは、SignedDataパーツまたは少なくともそのS/MIMEバリアント(OpenSSLでも実行可能)を処理でき、残りのp7bパーツは、すべてではないにしてもほとんどの証明書で処理できます/セキュリティソフトウェア。
RFC 451(および2510)には、 lots の機能とオプションを掘り下げていないため、そこに何かがあるとすぐに信じますあなたが望むものですが、私はそれの実装を見たことがありません。両方(または全部?)でソフトウェアを記述し、サポートする必要があるかもしれません。