自己管理型クラスターで X. 509証明書をローテーション
バージョン 7.0 で追加。
クラスター メンバーは、同じ配置内の他のサーバーを識別するために、 メンバーシップ認証に X. 509証明書を使用できます。
サーバーは接続リクエストを受信すると、DN(Distinguished Name、識別名)値または証明書の拡張値 string を、 clusterAuthX509
設定とtlsClusterAuthX509Override
パラメーターの構成値と比較します。 値が一致する場合は、接続をクラスター ノードとして扱います。
新しい証明書を使用するクラスターは、証明書ローテーション手順中に、 tlsClusterAuthX509Override
パラメータを使用して、異なる DN 属性を持つ X.509 証明書を受け入れることができます。 すべてのノードが新しい 値を持つ証明書を使用したら、オーバーライドを削除して、古くなった証明書の拒否を開始します。
注意
net.tls.clusterAuthX509
設定を使用せず、更新後に証明書をローテーションするクラスターで証明書をローテーションするには、「 x のローリング更新 」を参照してください。自己管理型クラスター上の新しい DN を含む509証明書
このタスクについて
メンバー証明書( clusterFile
とcertificateKeyFile
設定を使用して設定)の識別名(DN)値が10gen
組織と10gen Server
組織単位( 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 証明書がメンバーシップ証明書とその他のすべての要件を満たし、クラスター構成が識別名(DN)値を使用してピア証明書を識別することを前提としています。
詳細については、「ノード証明書の要件 」を参照してください。
手順
これらの手順では、 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 証明書からの接続を受け入れなくなります。