信頼できないCAを信頼する-システムがそれを信頼する方法を制限できますか?


32

(プログラミングコードよりもOS構成に関係していると感じているため、StackOverflowではなくServerFaultに投稿されています)。

現在、サードパーティのWebサービスに接続するシステムを保守する責任があります。このWebサービスには十分なクライアント認証証明書が必要ですが、Webサービス自体は、自己作成ルート証明機関証明書(クライアント認証証明書を作成するのと同じルート)によって作成された自己署名証明書で保護されます。

現在のサービス証明書を既知の信頼できるリストに追加し、自己作成の認証局証明書を無視するだけで十分です。残念ながら、サービス証明書は定期的に変更されるため、認証局証明書は信頼できる必要があります。サービス証明書が更新されます。

ただし、Webサービスを実行している会社での経験に基づいて(個人的に)CA証明書を信頼していません-Webに漏洩しても驚かないでしょう-心配なことに、CA証明書にはキー使用制限がありません(外部のMITM攻撃は可能ですが、リモートではありますが、コード署名に使用される証明書の漏えいについてより懸念しています)。

コンピューター(現在はサーバーボックスですが、将来の通常のデスクトップクライアントボックス)にCAを信頼するように指示することはできますが、特定のキー使用法と可能なサブジェクト名(ドメイン名) )?

サーバーは現在Windows Server 2012 R2ですが、デスクトップコンピューターはすべてWindowsボックスですが、Linuxボックスで実行できます。


3
少なくともLinuxでは、多くのアプリケーションにはピアCA証明書の場所を指定するオプションがあるため、このCAのスコープをそれを使用するアプリケーションのみに制限できます。@CryptoGuyの答えはLinuxでも機能しますが、Windows固有のものは何もありません。
エデルディル

1
@Edheldil:ただし、実装固有です。たとえば、Windowsは、たとえばNSSやGnuTLSよりもずっと長い間、X.509名の制約をサポートしています。
-grawity

システムはこのサードパーティサービスに接続します。システム上のクライアントコードは、システム全体ではなく、そのクライアントコードに対してのみ実行されるように、そのサービスのCAを信頼するように構成できますか?
カスタリア

@Castagliaホストシステムとは独立して動作する独自の証明書検証コードを記述できますが、システム全体の証明書サービスを使用するクライアントソフトウェアには制御できないものがあります。

回答:


40

はい、可能です。Windowsの場合、相互認証または限定従属と呼ばれる機能があります。

考えは、環境でサードパーティの発行CA証明書に署名することです。その結果、リモートSSL証明書は独自のルートCA証明書にチェーンされます。考えられる不正な証明書から身を守るためにName Constraints、受け入れ可能な名前のリストを指定する証明書拡張機能を実装します。サードパーティCAが他の名前(Name Constraints拡張機能で明示的に指定されていない)の証明書を発行した場合、CryptoAPIプロバイダーによって自動的に拒否されます。

名前の制約に加えてApplication Policies、相互証明書で証明書の拡張子を定義することにより、拡張キー使用法の制約を記述することができます。したがって、信頼プロバイダーは、Application Policies拡張機能で指定された使用法のみを正常に検証します。

詳細:Windows Server 2003を使用した相互認証と限定従属の計画と実装

追伸、この記事はWindows Server 2003に対して書かれていますが、最新のWindows Serverバージョンにも適用されます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.