Rotate X.509 Certificates with clusterAuthX509 Attributes on Self-Managed Clusters
バージョン 7.0 で追加。
Cluster members can use X.509 certificates
for membership authentication to identify other servers
in the same deployment. This tutorial describes how to perform
a rolling update to rotate X.509 certificates on a cluster
that uses the net.tls.clusterAuthX509.attributes settings to configure
the cluster members' Distinguished Name (DN) attributes.
注意
To perform a rolling update to rotate certificates on a cluster that doesn't
use the net.tls.clusterAuthX509 settings and won't after the update,
see Rotate X.509 Certificates without clusterAuthX509 Attributes on Self-Managed Clusters.
net.tls.clusterAuthX509.attributes設定で構成されたサーバーは接続リクエストを受信すると、提示された証明書の フィールドの DN（Distinguished Name、識別名）属性をsubject attributes設定とtlsClusterAuthX509Override パラメーターの構成値と比較します。値が一致する場合は、接続をクラスター ノードとして扱います。
状況によっては、組織がその名前を変更した場合など、新しい識別名（DN）を持つ新しい証明書に、ノード証明書を更新する必要がある場合があります。 ローリング アップデートでは、メンバー証明書が一度に 1 つずつ更新されるため、配置のダウンタイムは発生しません。
Clusters adopting new certificates can use the
tlsClusterAuthX509Override parameter to accept X.509 certificates
with different subject DN attributes during the certificate rotation procedure. Once
all members use certificates with the new value, remove the override to begin
rejecting the now out of date certificates.
このタスクについて
と 設定を使用して設定されたメンバー証明書が、 組織とclusterFile certificateKeyFile組織単位を使用する識別名（DN）属性を持つレプリカセットを検討します。10gen10gen Serverこれらの DN 属性は、net.tls.clusterAuthX509.attributes 設定を使用して設定されます。
このレプリカセットのノードには、次の構成ファイルがあります。
security: clusterAuthMode: x509 net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/10gen-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/10gen-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=10gen, OU=10gen Server
The following procedure updates each replica set member's X.509 certificates to new
certificates that have DN attributes that use the
MongoDB organization and MongoDB Server organizational unit.
注意
The following procedure assumes that the new X.509 certificates meet membership certificate and all other requirements and that the cluster configuration identifies peer certificates using Distinguished Name (DN) values. For more information, see ノード証明書の要件.
手順
これらの手順では、 net.tls.clusterAuthX509.attributes設定で構成されたクラスターで新しい X.509 証明書を使用するようにメンバー証明書を更新します。
新しい証明書の識別名（DN）は、組織（O）属性を10genからMongoDBに変更し、組織単位（OU）属性を10gen ServerからMongoDB Serverに変更します。
TLS クラスターのメンバーシップ構成の更新
各サーバーの構成ファイルを更新します。
新しい証明書の 値を使用するには
attributesの設定を変更します古い証明書の DN 属性を使用するには、
tlsClusterAuthX509Overrideパラメータを設定します。
以下に例を挙げます。
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509 setParameter: tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }
セカンダリ クラスター ノードの再起動
各セカンダリ クラスター ノードを再起動します。
mongoshを使用して各セカンダリ クラスター メンバーに接続し、db.shutdownServer()メソッドを使用してサーバーを停止します。use admin db.shutdownServer() サーバーを再起動します。
メンバーの状態を判別するには、
rs.status()メソッドを使用します。rs.status().members このノードの
stateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。
レプリカセット内のセカンダリ サーバーは、新しい DN 属性を持つ証明書を使用するノードからのピア接続を受け入れるようになりました。
プライマリ クラスター ノードの再起動
プライマリ ノードを再起動します。
mongoshを使用してプライマリに接続し、rs.stepDown()メソッドを使用してノードをプライマリから降格します。rs.stepDown() クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。
サーバーをシャットダウンするには、
db.shutdownServer()メソッドを使用します。use admin db.shutdownServer() サーバーを再起動します。
レプリカセット内のプライマリ サーバーが降格してセカンダリとして再起動し、新しい DN 属性を持つ証明書を使用するノードからのピア接続を受け入れるようになりました。
TLS 証明書の更新
各サーバーの構成ファイルを更新します。
新しい証明書を使用するには
net.tls.certificateKeyFile設定を変更します。新しい証明書を使用するには
net.tls.clusterFile設定を変更します。
以下に例を挙げます。
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server2.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster2.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509 setParameter: tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }
セカンダリ クラスター ノードの再起動
各セカンダリ クラスター ノードを再起動します。
mongoshを使用して各セカンダリ クラスター メンバーに接続し、db.shutdownServer()メソッドを使用してサーバーを停止します。use admin db.shutdownServer() サーバーを再起動します。
メンバーの状態を判別するには、
rs.status()メソッドを使用します。rs.status().members このノードの
stateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。
レプリカセット内のセカンダリ サーバーが新しい X.509 証明書を使用するようになりました。
プライマリ クラスター ノードの再起動
プライマリ ノードを再起動します。
mongoshを使用してプライマリに接続し、rs.stepDown()メソッドを使用してノードをプライマリから降格します。rs.stepDown() クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。
サーバーをシャットダウンするには、
db.shutdownServer()メソッドを使用します。use admin db.shutdownServer() サーバーを再起動します。
レプリカセット内のプライマリ サーバーが降格し、新しい X.509 証明書を使用するセカンダリとして再起動します。
DN 認証オーバーライド構成の削除
クラスターのすべてのノードが新しい X.509 証明書を使用するようになりました。構成ファイルを更新して パラメータのsetParameter tlsClusterAuthX509Override設定を削除します。
以下に例を挙げます。
net: tls: mode: requireTLS certificateKeyFile: /etc/mycerts/mongodb-server1.pem CAFile: /etc/mycerts/ca.pem clusterFile: /etc/mycerts/mongodb-cluster1.pem clusterCAFile: /etc/mycerts/ca.pem clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server security: clusterAuthMode: x509
これにより、サーバーは起動時に古い証明書設定を構成しないようになります。
セカンダリ クラスター ノードの再起動
各セカンダリ クラスター ノードを再起動します。
mongoshを使用して各セカンダリ クラスター メンバーに接続し、db.shutdownServer()メソッドを使用してサーバーを停止します。use admin db.shutdownServer() サーバーを再起動します。
メンバーの状態を判別するには、
rs.status()メソッドを使用します。rs.status().members このノードの
stateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。
レプリカセット内のセカンダリ サーバーが再起動し、古い X.509 証明書からの接続を受け入れなくなります。
プライマリ クラスター ノードの再起動
プライマリ ノードを再起動します。
mongoshを使用してプライマリに接続し、rs.stepDown()メソッドを使用してノードをプライマリから降格します。rs.stepDown() クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。
サーバーをシャットダウンするには、
db.shutdownServer()メソッドを使用します。use admin db.shutdownServer() サーバーを再起動します。
プライマリ サーバーが降格して再起動し、古い X.509 証明書からの接続を受け入れなくなります。