0

リードイン ... 私は SSL を介したアプリケーション セキュリティの専門家ではありませんが、本番環境で発生する可能性のあるすべてのシナリオを含むテスト環境を確立しようとしています。このために、さまざまなテスト クライアント証明書の発行者である認証局 (CA) のツリーと、ノード/サーバー証明書 (公開されているさまざまな Web サービスと統合する他のアプリケーションを表す複雑なテスト環境) があります。

これらの CA の構造は次のとおりです。サブ CA1、サブ CA2、およびサブ CA3 を署名/発行したルート CA。これらのサブは、環境内のさまざまなノードとクライアントのすべての証明書に署名/発行しています。

ここで質問です....私のアプリケーションのトラストストアでは、Sub CA1 と Sub CA2 によって署名されたすべてのものを信頼したいと思いますが、Sub CA3 (信頼されていない) は信頼したくありません。これは、トラストストアに (1) サブ CA1 とサブ CA2 のみを含める必要がある、または (2) ルート CA、サブ CA1、およびサブ CA2 を含める必要があるということですか?

このトラスト チェーンをトラストストアで表現する適切な方法がわかりません。将来的には、サブ CA4 (ルート CA によって署名/発行されたもの) も追加したいと考えていますが、それをテスト目的で証明書失効リスト (CRL) に追加したいと考えています。

事前に、これに関するご協力に感謝します。大変感謝しています。

4

1 に答える 1

0

警告：これをテストするつもりはないので、私の答えが正しいことを願っています。

あなたの基本的な仮定は正しいと思います。カスタムコードを記述せずに信頼を選択的に取り消すことができるとは思わないので、トラストストアには完全に信頼されている証明書のみを含める必要があります。したがって、ルートCAを除外し、オプション（1）を選択します。

ご覧のとおり、このようなきめ細かいアクセス制御を適用しようとすることは、Java（および他のほとんどすべてのシステム）のX509証明書ベースの認証モデルには適していません。これらは基本的に、SSL証明書とコード署名証明書のID検証をVerisign、Thawte、GoDaddy、GlobalSignなどにアウトソーシングするように設計されています。自己署名証明書を含む他のモデルをサポートできますが、事前のかなりの苦痛と継続的なメンテナンスの問題がないわけではありません。

于 2010-05-30T13:41:48.063 に答える