%20%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%8C%E6%9C%89%E5%8A%B9%E3%81%AA%E7%BD%B2%E5%90%8D%E4%BB%98%E3%81%8D%E8%A8%BC%E6%98%8E%E6%9B%B8%E3%82%92%E4%BF%A1%E9%A0%BC%E3%81%97%E3%81%AA%E3%81%84%E3%81%93%E3%81%A8%E3%81%8C%E3%81%82%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B%3F.png)
これはやや標準的な質問ですが、よろしいでしょうか。
私は、Linux サーバー上で実行されているクライアント (通常は Java アプリケーション) が有効な署名付き証明書 (ブラウザーによって信頼されている証明書) を信頼しない状況をトラブルシューティングすることがよくあります。通常の簡単な解決策は、証明書を Java cacerts 信頼ストアに追加することですが、なぜこれが必要なのか疑問に思っています。
私の理解では、2つの可能性があります。
- サーバー側が完全なチェーン (エンド エンティティ証明書 + 中間証明書) を正しい順序で送信しておらず、クライアントが中間証明書を信頼していません (おそらく古すぎるため)。
- クライアント信頼ストアには、信頼アンカーとして使用するルート証明書が含まれていません (古すぎるためと思われます)。
それは正しいでしょうか? もしそうなら、エンドエンティティ証明書の信頼を強制する別の可能性として次のことが考えられます:
- 完全なチェーンを送信するようにサーバー アプリケーションを構成します。
- クライアント (例: Java) を新しいバージョンにアップグレードします。私の場合、通常、使用できる Java のメジャー リリースはソフトウェアの前提条件によって制限されますが、各マイナー リリースには更新された信頼ストアが含まれている可能性があります。
ご説明のご意見があれば、ぜひお聞かせください。