x.509

クライアント証明書の要件

クライアント証明書の要件:

• 単一の認証局（CA）がクライアントとサーバーの両方の証明書を発行する必要があります。

• それぞれの固有の MongoDB ユーザーに固有の証明書が必要です。

• X.509証明書は期限切れであっては なりません 。

  注意

  mongod または mongos は、提示された x.509 証明書が mongod/mongos のホストシステム時間から 30 日以内に期限切れになる場合、接続時に警告を記録します。

• クライアント証明書には次のフィールドが含まれている必要があります。

  keyUsage = digitalSignature
  extendedKeyUsage = clientAuth

• 次のクライアント証明書属性の少なくとも 1 つは、net.tls.clusterFile および net.tls.certificateKeyFile のどちらのサーバー証明書の属性とも異なる必要があります。

  • 組織（O）

  • 組織単位（OU）

  • ドメイン コンポーネント（DC）

• 識別名（DN） を含む x.509 クライアント証明書の subject は、x.509 ノード証明書の subject と異なる必要があります。MongoDB 配置に tlsX509ClusterAuthDNOverride が設定されている場合、クライアント x.509 証明書のサブジェクトはその値と一致してはいけません。

  重要

  クライアントX.509 証明書のサブジェクトがO OUDC509ノード X. 証明書の 、 、 属性（または設定されている場合はtlsX509ClusterAuthDNOverride ）と完全に一致する場合、クライアント接続は受け入れられます、完全な権限が付与され、ログに警告メッセージが表示されます。

  クラスター ノードの x509 証明書のみが、O、OU、および DC の属性が同じ組み合わせを使用する必要があります。

MongoDB ユーザーおよび $external データベース

クライアント証明書を使用して認証するには、まずクライアント証明書の subject を MongoDB ユーザーとして $external データベースに追加する必要があります。$external データベースはユーザーの 認証データベース です。

一意の X.509クライアント証明書はそれぞれ 1 人のMongoDBユーザーに対する証明書です。1 つのクライアント証明書を使用して複数のMongoDBユーザーを認証することはできません。

$external認証ユーザー（Kerberos、LDAP、または X.509 ユーザー）でクライアント セッションと因果整合性の保証を使用するには、ユーザー名を 10 k バイトより大きくすることはできません。

TLS 接続 X509 証明書のスタートアップ警告

MongoDB 5.0 以降では、証明書にサブジェクト代替名属性が含まれていない場合、mongod と mongos で起動時の警告が発せられるようになっています。

以下のプラットフォームは、コモンネームの検証をサポートしていません。

• iOS 13 以降

• MacOS 10.15 以降

• Go 1.15 以降

これらのプラットフォームを使用するクライアントは、CommonName 属性によって指定されているホスト名の x.509 証明書を使用する MongoDB サーバーに対して認証を行いません。

ノード証明書の要件

ノード証明書を使用して、シャーディングされたクラスターまたはレプリカセットへのメンバーシップを検証します。 メンバー証明書はnet.tls.clusterFileとnet.tls.certificateKeyFileに保存されています。 ノード証明書の要件:

• 単一の認証局 (CA) が、シャーディングされたクラスターまたはレプリカセットのノードすべての x.509 証明書を発行する必要があります。

• x.509証明書は期限切れであってはなりません。

  注意

  mongodmongosX.509 証明書が30 mongod/mongosホスト システム時間から 日以内に期限切れになる場合、 / は接続時に警告を記録します。

• メンバー証明書のsubjectにある識別名（ DN ）は、次の属性の少なくとも 1 つに空でない値を指定する必要があります。

  • 組織 (O)

  • 組織単位 (OU)

  • ドメインコンポーネント (DC)

• マルチクラスター配置では、各クラスターで異なる X. 509ノード証明書を使用する必要があります。 各証明書のO 、 OU 、およびDC識別名（DN）フィールドに一意の値が必要です。

  2 つのクラスターが同じ DN 値を持つ証明書を持っている場合、一方のクラスターで侵害されたサーバーは、もう一方のクラスターのノードとして認証できます。

• 各クラスター ノード証明書には、 net.tls.clusterFile } 証明書とnet.tls.certificateKeyFile証明書に同一のO 、 OU 、およびDCが含まれている必要があります。 これは、 tlsX509ClusterAuthDNOverride値が設定されている場合は、にも適用されます。 Attribute order doesn't matter.

  以下に例を示します。 以下の 2 つのDNには、 OとOUの指定が一致していますが、 DCは指定されていません。

  CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
  C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

  次の例は誤りです。 DNが一致しないためです。 一方のDNにはOU仕様が 2 つあり、もう一方のOU仕様は 1 つだけです。

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• コモンネーム（ CN ）またはサブジェクト代替名（ SAN ）のいずれかのエントリは、他のクラスター ノードのサーバー ホスト名と一致する必要があります。 MongoDB 4.2 以降では、 SANを比較する際に、MongoDB は DNS 名または IP アドレスのいずれかを比較できます。 以前のバージョンでは MongoDB は DNS 名のみを比較していました。

  たとえば、クラスターの証明書には次のsubjectが含まれる可能性があります。

  subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US

• certificateKeyFile として使用される証明書に extendedKeyUsage が含まれている場合、値には clientAuth（「TLS Web クライアント認証」）と serverAuth（「TLS Web サーバー認証」）の両方を含める必要があります。

  extendedKeyUsage = clientAuth, serverAuth

• clusterFile として使用される証明書に extendedKeyUsage が含まれている場合、値には clientAuth が含まれている必要があります。

  extendedKeyUsage = clientAuth

メンバーシップ認証のための MongoDB 設定

TLS は、レプリカセットの各ノード（各 mongod インスタンス）間、またはシャーディングされたクラスター（各 mongod インスタンスと mongos インスタンス）間の認証に使用できます。

内部認証に TLS を使用するには、次の設定を使用します。

• security.clusterAuthMode または --clusterAuthMode を x509 に設定

• net.tls.clusterFile or --tlsClusterFile

mongodインスタンスとmongosインスタンスは証明書鍵ファイルを使用してクライアントに ID を証明しますが、証明書鍵ファイルはメンバーシップ認証に使用することもできます。 クラスター ファイルを指定しない場合、メンバーはメンバーシップ認証に証明書鍵ファイルを使用します。 net.tls.certificateKeyFileまたは--tlsCertificateKeyFileを使用して証明書鍵ファイルを指定します。

証明書キーファイルをクライアント認証とメンバーシップ認証の両方に使用するには、証明書は次のいずれかを行う必要があります。

• extendedKeyUsage を省略する、または

• 特定 extendedKeyUsage = serverAuth, clientAuth