SRV DNSレコードを使用している場合、TLS証明書にはどのような名前を入れますか?たとえば、2つのサーバー(klas1とklas2)でslapdを設定していて、これらのDNSレコードを(バインドゾーンファイルスタイル表記を使用して)定義している場合:
_ldap._tcp.example.com. IN SRV 10 0 389 klas1.example.com.
_ldap._tcp.example.com. IN SRV 20 0 389 klas2.example.com.
klas1.example.com. A 192.168.0.1
klas2.example.com. A 192.168.0.2
クライアントがldap://example.com/に接続するように構成されていると思います。ただし、サーバーでTLS証明書を生成する場合、「example.com」という名前で生成しますか、それとも「klas1.example.com」という名前で生成しますか、それとも両方が必要ですか?
証明書はホスト名と一致する必要があります。つまり、サーバーの対応するA
レコードです。個別のklas1.example.com
&klas2.example.com
証明書または共有ワイルドカード*.example.com
証明書を持つことができますが、example.com
は一致しません。
SRV
レコードは、サービス検出のためにDNSレベルでのみ使用されるため、証明書は必要ありません。
証明書の共通名またはSubjectAltName.DNSは、LDAPURIで最初に指定された名前と一致する必要があります。付録B.3のRFC6125( https://tools.ietf.org/html/rfc6125#appendix-B. )は次のように述べています。
3.6。サーバーIDチェック
クライアントは、サーバーのホスト名の理解を確認する必要があります
サーバーのIDで表示されるサーバーのIDに対して
man-in-the-middle攻撃を防ぐための証明書メッセージ。マッチングは、次のルールに従って実行されます。
oクライアントは、LDAP接続を開くために使用したサーバーのホスト名を、サーバーの証明書に示されているサーバー名と比較する値として使用する必要があります。クライアントは、サーバーの正規DNS名またはその他の派生形式の名前を使用してはなりません(MUSTNOT)。
同じロジックが、SIPなどのSRVレコードを使用する他のプロトコルにも適用されることに注意してください。これは、セキュリティの観点からは多少論理的です。ホストのみがチェックされている場合、ホスト名が最初に照会されたドメイン名とは無関係のノードに接続を迂回させることにより、中間者攻撃を実行するのは簡単です。
必要なのはホストエントリ(Aレコード)のみで、サービスレコードは接続自体ではなく検出に使用されます。