問題タブ [pki]

ユーザーがユーザー名/パスワード認証に加えて、クライアント証明書を使用して登録し、その後認証できるシステムを設計しています。

クライアント証明書は、構成された認証局のリストによって発行された有効な証明書である必要があり、提示されたときにチェック (検証) されます。

登録フェーズでは、クライアント証明書で認証するユーザーを内部の「ユーザー」にマップできるように、クライアント証明書の一部をユーザー リポジトリ (DB、LDAP など) に保存する必要があります。

かなり明白な選択肢の 1 つは、証明書のフィンガープリントを使用することです。ただし、衝突が発生する可能性があるため (発生する可能性は低くても)、フィンガープリント自体では十分ではないため、証明書から追加情報を保存する必要があります。この SO の質問は、この点でも有益です。

RFC 2459は、証明書のシリアル番号が特定の CA 内で一意でなければならないことを定義しています (4.1.2.2)。

これらすべてを組み合わせて、登録ユーザーごとに証明書のシリアル番号と証明書の発行者を保存することを考えています。クライアント証明書が検証されて有効であることを考えると、これは各クライアント証明書を一意に識別する必要があります。そうすれば、クライアント証明書が更新された場合でも、それは引き続き有効です (シリアル番号は同じままで、発行者も同じです)。

私は何か見落としてますか？

Java で記述された複数のクライアントと単一のサーバーを含むネットワークを構築しようとしています。署名付き証明書のためにサーバーに送信できる CSR をクライアント側で自動的に生成する方法を見つけようとしています。Java で公開鍵と秘密鍵のペアを生成できましたが、CSR の生成方法がわかりません。たぶん、私はこれを間違った方法で行っていると考えています! 助けてください！

ユーザーの操作なしでクライアント側の SSL 証明書を更新するためのベスト プラクティスは何ですか?

具体的
には、SSL秘密鍵/公開x.509証明書を備えたサーバーがあります。すべてのクライアントは、SSL を介してこのサーバーと通信します。SSL 接続を確立するには、すべてのクライアントがサーバーの公開証明書を信頼できる場所 (トラストストア) にインポートする必要があります。

(クライアント) インストール時にサーバーの証明書を取得することは問題ではありません。これは、インストーラーが (SSL によって) サーバーに接続し、サーバーの公開鍵 (または会社のルート証明書) を取得できるためです。その後、インストーラーは視覚的な検証のために証明書をユーザーに表示できますが、これは十分に安全です。

サーバー証明書 (または企業 CA) の有効期限が切れた後はどうなりますか?
または、サーバー証明書が誤って変更された場合はどうなりますか?

すべてのクライアントを新しいサーバー SSL 証明書 (CA) で (自動的に) 更新するためのベスト プラクティスは何ですか? インストール後、クライアントはバックグラウンド プロセスであり、視覚的なユーザー インタラクションは不可能であることに注意してください。

もちろん、最も簡単な方法は、インフラ管理者がすべてのクライアントを手動で更新することです。

ユーザーの介入なしにクライアントの証明書を自動的に更新するための既知の良い方法があるかどうか疑問に思っていますか?

https を使用して銀行口座にログインすると、ログイン情報を入力する前にサーバー側の SSL 認証のみが行われます。私のブラウザは、SSL セッション中にサーバーからの証明書情報に基づいてサーバー認証を行います。サーバー証明書を信頼できる証明書としてブラウザーに手動でインポートする必要はありませんでした。実行時に SSL 交換中に発生します。

一方で、インストールガイドを調べたときに証明書を手動でインポートする必要があるアプリケーションも見てきました (たとえば、keytool を使用)。

質問: SSL セッションの開始時に証明書情報が交換される場合、各側には相手側を認証するのに十分な情報があります。一部のアプリでは、クライアントとサーバーの間で相互に証明書を手動でインポートする必要があるのはなぜですか。どちらかまたは両方の側の認証です。

以下の回答に基づく追加情報: クライアント側の SSL 認証をオンにして、クライアント サーバー モデルに基づく商用ソフトウェアをインストールするシナリオについて言及していました。サーバーをマシン A にインストールし、2 つのクライアントをすべてプライベート ネットワーク内の異なるマシンにインストールしました。インストール中に、サーバーは自己署名証明書をローカルに生成します。2 クライアントも同様です。インストールが完了すると、クライアントの証明書をサーバー マシンにコピーし、それらを信頼できる証明書として手動でインポートするように求められました。また、サーバー証明書をクライアント マシンにコピーし、信頼できるストアにインポートします。彼らは、証明書のインポートを実行するために、Java keytool の上にラッパー ツールを提供しました。どうしてこの手動インポートはここで必要ですか? いずれにせよ、クライアントとサーバーは SSL ハンドシェイク中に証明書情報を交換し、認証を実行します。繰り返しますが、これらは自己署名証明書であり、CA が関与しています。

公開鍵を使用して分離された XML 署名を検証したいと考えています。

gpg と openssl を使用してみましたが、成功しませんでした。公開鍵を使用して検証する手順を誰かに教えてもらえますか?

誰かが次のことについて私を助けてくれませんか？
RFC2560は、OCSPレスポンダー証明書（応答の発信）をいつ受け入れることができるかを定義します。

私の質問は次のとおり
です。OCSPレスポンダーの証明書が検証パスのトラストアンカーによって署名されている場合、それも受け入れられたと見なされますか？
私はそうあるべきだという印象を持っていますが、これはRFCから明示的に上に述べられておらず、これに関する明示的な参照を見つけることができませんでした。

私がRFCを読んだところ、TAによって署名されていても、OCSP応答には有効ではないということです。
どんな助けでも大歓迎
です注：それが重要な場合に備えて、私はこれについてJavaで作業しています

更新：
RFCのセクション2.2：

すべての決定的な応答メッセージは、デジタル署名されている必要があります。応答に署名するために使用されるキー
は、次のいずれかに属している必要があります。

-問題の証明書を発行したCA-
公開鍵が要求者によって信頼されている信頼できるレスポンダー
-CAによって直接発行された特別にマークされた証明書を保持するCA指定レスポンダー（承認されたレスポンダー）。そのCAのOCSP応答を発行します

ポイント2は私には曖昧に思えます。
これは、次のことを意味します
。a）信頼できるPKであるため、トラストアンカーが受け入れられる
、または
b）最初の引用でポイント（1）の意味を持つ。ここでJavaで行われます：

OCSP応答の定義でのレスポンダーIDの使用については明確ではありません。

JavaのPKIXAPIを介してOCSPチェックを行っています。

（OCSP応答処理中に）取得したサードパーティライブラリを使用すると、次のようになります。

java.security.cert.CertPathValidatorException：失効ステータスを判別できませんでした：応答のResponderIDがレスポンダー証明書と一致しませんでした。

デフォルトのプロバイダー（SUNなど）に切り替えると、そのような例外は発生せず、失効チェックは正常に機能します。

これをさらに調べると、この例外は、応答者の識別子が署名証明書の公開鍵の鍵ハッシュを使用するか、署名証明書の主題を使用するかに関連しているようです。

ただし、違いは何ですか。また、SUNの実装でOCSP応答に問題がない理由はわかりません。

ここで何が起こっているのかを理解する前に、結論に飛びついて他のライブラリを削除したくありません。

誰かが私がここで問題になる可能性があるものを理解するのを手伝ってくれませんか？

クライアントマシンでDOD発行のCAC、ActivClient、およびIEを使用して、JBoss4.2.3にデプロイされたWebアプリケーションでクライアント証明書認証を有効にしようとしています。概念実証として、ソフト証明書（自己署名証明書を生成し、PKCS12形式に変換し、IEにインポート）を使用して、JMXコンソールでクライアント証明書認証を機能させることができました。また、サンプル（デモ）CACを使用して、おそらくデモユーザーに対してオンラインでTriCareを認証することもできます。

ただし、証明書をCACからエクスポートし、CNエントリをエイリアスとして使用してJKSトラストストアにインポートしようとしましたが（必要かどうかはわかりません）、まったく機能しません。JBossログに「NullCertificateinChain」というエラーが表示され、クライアントで証明書の選択またはPINの入力を求めるプロンプトが表示されません。私の最善の理論は、トラストストアに証明書がないため、クライアントにどの証明書を要求するかはわかりませんが、この疑いを確認する方法や、何が間違っているのかはわかりません。

JBossをApacheでフロント化すると、このプロセスが簡単になりますか？（これは内部アプリであるため、JBossをWebサーバーにしました。）

古いバージョンのJBossにアップグレードすると役立ちますか？

何が起こっているのかをより明確に把握できるデバッグステートメントをどこかで有効にできますか？

ステップバイステップのドキュメントはどこかにありますか？これに関する専門知識を得るにはどうすればよいですか？私は、JBoss 4オンラインドキュメント、「JBoss in Action」、「Core Security Patterns」、およびこの問題に触れるいくつかのQ＆Aに基づいてソリューションをまとめています。

どんな助けでも大歓迎です！