x.509

項目一覧

認証局

クライアント x.509 証明書
ノード x.509 証明書

MongoDB はクライアント認証およびレプリカセットやシャーディングされたクラスターのノードの内部認証に対して x.509 証明書による認証をサポートします。

認証局

実稼働環境で使用する場合、MongoDB の配置には、認証局によって生成および署名された有効な証明書を使用する必要があります。ユーザーまたは組織は、独立した認証局を作成して維持することも、サードパーティの TLS ベンダーによって生成された証明書を使用することもできます。証明書の取得と管理については、このドキュメントの範囲外です。

クライアント x.509 証明書

サーバーで認証するために、クライアントはユーザー名とパスワードの代わりに 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 証明書のサブジェクトがノードの x.509 証明書の O、OU、および DC 属性（または、設定されている場合はtlsX509ClusterAuthDNOverride）と完全に一致する場合、クライアント接続は受け入れられ、完全な権限が付与され、ログに警告メッセージが表示されます。
クラスターノードの x509 証明書のみが、O、OU、および DC の属性が同じ組み合わせを使用する必要があります。

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

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

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

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

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

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

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

iOS 13 以降
MacOS 10.15 以降
Go 1.15 以降

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

ノード x.509 証明書

シャーディングされたクラスターとレプリカセットのノード間の内部認証には、キーファイルの代わりに x.509 証明書を使用できます。

ノード証明書の要件

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

単一の認証局 (CA) が、シャーディングされたクラスターまたはレプリカセットのノードすべての x.509 証明書を発行する必要があります。
x.509証明書は期限切れであってはなりません。
注意
が x を表示した場合、 mongod / mongosは接続時に警告を記録します。 509証明書はmongod/mongosホストシステム時間から30日以内に期限切れになります。
メンバー証明書の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

戻る

クライアントの認証

認証局