自己管理型クラスターで clusterAuthX509 属性を使用して x.509 証明書をローテーション
バージョン 7.0 で追加。
クラスター メンバーは、同じ配置内の他のサーバーを識別するために、メンバー認証に x.509 証明書を使用できます。このチュートリアルでは、509 net.tls.clusterAuthX509.attributes設定を使用してクラスター ノードの識別名（DN）属性を構成するクラスターで x. 証明書をローテーションする方法について説明します。
注意
設定を使用せず、更新後に証明書をローテーションするクラスターで証明書をローテーションするには、「 509509自己管理型クラスターでnet.tls.clusterAuthX509 clusterAuthX 属性を使用せずに x. 証明書をローテーションする 」を参照してください。
net.tls.clusterAuthX509.attributes設定で構成されたサーバーは接続リクエストを受信すると、提示された証明書の フィールドの DN（Distinguished Name、識別名）属性をsubject attributes設定とtlsClusterAuthX509Override パラメーターの構成値と比較します。値が一致する場合は、接続をクラスター ノードとして扱います。
状況によっては、組織がその名前を変更した場合など、新しい識別名（DN）を持つ新しい証明書に、ノード証明書を更新する必要がある場合があります。 ローリング アップデートでは、メンバー証明書が一度に 1 つずつ更新されるため、配置のダウンタイムは発生しません。
新しい証明書を使用するクラスターは、証明書ローテーション手順中に、tlsClusterAuthX509Override 509パラメータを使用して、異なるサブジェクト DN 属性を持つ x. 証明書を受け入れることができます。すべてのノードが新しい 値を持つ証明書を使用したら、オーバーライドを削除して、古くなった証明書の拒否を開始します。
このタスクについて
と 設定を使用して設定されたメンバー証明書が、 組織と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
次の手順では、各レプリカセットノードの x.509 証明書を、MongoDB組織と MongoDB Server 組織単位を使用する DN 属性を持つ新しい証明書に更新します。
注意
次の手順では、新しい x.509 証明書がメンバーシップ証明書とその他のすべての要件を満たし、クラスター構成が識別名（DN）値を使用してピア証明書を識別することを前提としています。 詳細については、「 ノード証明書の要件 」を参照してください。
手順
これらの手順では、 設定で構成されたクラスターで新しい x.509 net.tls.clusterAuthX509.attributes証明書を使用するようにメンバー証明書を更新します。
新しい証明書の識別名（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 setParametertlsClusterAuthX509Override証明書を使用するようになりました。構成ファイルを更新して パラメータの 設定を削除します。
以下に例を挙げます。
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 証明書からの接続を受け入れなくなります。