TLS相互認証を特定のTLS証明書に制限する

Question

ネットワーク内のすべてのx509証明書を発行する単一のCAを持つPKIがあります。 私のネットワークでは、すべてのサーバーとクライアントは、秘密鍵と共に、対応するキーストアに格納されている自分のCAからの証明書を所有しています。各サーバーとクライアントは、TLS相互認証が実行されているときにピアx509証明書の信頼チェーンを検証するために使用できるチェーンファイル内のCA証明書も持っています。大丈夫だ。 私はネットワーク上に2台のサーバーと2台のクライアントを持っていて、Client_BとServer_Bが行うべきであるように、Client_AとServer_Aがx509証明書を使ってTLS相互認証を成功させるようにしたいとします。 同時に、Client_AとServer_Bの間のTLS相互認証が成功しないことを確認したいと思います。 （Client_BとServer_Aの間でも有効です）。

私のネットワーク内のサーバーとクライアントは、信頼チェーンを検証するだけでなく、何らかのホワイトリストを尊重することができますか？

これはTLSレイヤでは実現できないかもしれませんが、それは私が明確にしたいことです。

Answer 1

あなたはこのTLSレイヤでクライアント証明書の検証

1. approaches- 2以下のいずれかを使用して達成することができます：各クライアントグループに別々の中間発行CAを作成します。たとえば、Server_Aのすべてのクライアントに対して、Ca_Client_Aという名前のCAを作成します。したがって、チェーンはrootCA - > Ca_Client_A - >クライアント証明書のように見えます。このCa_Client_AをServer-Aのトラストストアにインポートします。 Server_Aはca ca_Client_Aを発行しているクライアントへの接続を許可します。同様に、サーバーBのアプリケーション層でクライアント証明書の検証

2. によってクライアントグループBにサービスを提供するためにCa_Client_B中間CAを作成することができます。このため、あなたが制約を置く必要があるアプリケーションサーバーで認証ロジックを記述する必要があります成功した認証のために許可されたクライアント証明書 - シリアル番号またはキーワードと一致するCN名などです。

希望します。

Answer 2

TLSレイヤでこれを行う方法はありません。

ほとんどのTLSライブラリは、証明書交換中にコールバックオプションを提供します。これは、証明書をリストと照合するのに適した場所です。ライブラリ固有のバージョンの失敗/許容できないものを返すことは、通常、TLSハンドシェイクの失敗を引き起こし、データは送信されません。

Answer 3

これは、使用しているサーバーソフトウェアによって異なりますが、TLS標準ではありません。一部のソフトウェアパッケージは、特定のCA証明書によって発行された証明書を信頼するように構成できます。シナリオでは、これにより、CAによって発行されたすべての証明書が、CA証明書を信頼するように構成された任意のサーバーに接続できるようになります。特定の証明書、または特定のサブジェクト（証明書の識別名、subjectAltNameなど）を持つ証明書を信頼するように、他のサーバーソフトウェアを構成できます。したがって、接続しようとしている特定の「サーバー」によって異なります。これはApache Webサーバーですか？ IIS？ Tomcat？答えは、私たちが話しているサーバープラットフォームによって異なります。