レプリカセットまたはシャーディングされたクラスターのメンバーは、メンバー認証に X.509 証明書を使用して、同じ配置内の他のサーバーを識別できます。このチュートリアルでは、識別名（DN）属性を構成するために net.tls.clusterAuthX509 設定を使用していないクラスターで X.509 証明書をローテーションするためのローリング アップデートを実行する方法について説明します。
注意
net.tls.clusterAuthX509 設定を使用するクラスター、または更新後にこれらの設定を使用するクラスターで証明書をローテーションするには、「自己管理型クラスターで clusterAuthX509 属性を使用して X.509 証明書をローテーションする」を参照してください。 。
サーバーノードは接続リクエストを受信すると、提示された証明書の subjectフィールドの DN（Distinguished Name、識別名）属性と、自分の証明書のサブジェクト DN 属性を比較します。 証明書は、サブジェクトに組織（O）、組織単位（OU）、およびドメインコンポーネント（DC）の属性が同じ値を含む場合は一致します。 サーバーの構成ファイルでは、 パラメータで一致させるために使用する代替の DNtlsX509ClusterAuthDNOverride 属性を指定することもできます。サーバーのサブジェクト DN 属性または構成されたtlsX509ClusterAuthDNOverride 値が、提示された証明書のサブジェクト DN 属性と一致する場合、サーバーノードは接続をクラスター ノードとして扱います。
状況によっては、組織がその名前を変更した場合など、新しいサブジェクト識別名（DN）属性を持つ新しい証明書に、ノード証明書を更新する必要がある場合があります。 ローリング アップデートでは、メンバー証明書が一度に 1 つずつ更新されるため、配置のダウンタイムは発生しません。
新しい証明書を使用するクラスターは、証明書ローテーション手順中に、tlsX509ClusterAuthDNOverride 509パラメータを使用して、異なるサブジェクト DN 属性を持つ x. 証明書を受け入れることができます。すべてのノードが新しい 値を持つ証明書を使用したら、オーバーライドを削除して、古くなった証明書の拒否を開始します。
このタスクについて
clusterFile と certificateKeyFile 設定を使用して設定された各ノードの X.509 証明書のサブジェクト DN 属性が "OU=10gen Server,O=10gen" であるレプリカセットを考えてみましょう。
このレプリカセットのノードには、次の構成ファイルがあります。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/10gen-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
次の手順では、各メンバーの証明書を、サブジェクト DN 属性が "OU=MongoDB Server, O=MongoDB" である新しい証明書に更新します。
注意
次の手順では、新しい X.509 証明書がメンバーシップ証明書とその他のすべての要件を満たし、クラスター構成が識別名（DN）値を使用してピア証明書を識別することを前提としています。詳細については、「 ノード証明書の要件 」を参照してください。
手順
すべてのノードにオーバーライド パラメーターを設定します。
ローリング更新中に、メンバーは新しい構成で一度に 1 つずつ再起動されます。 古いサブジェクト DN 属性を持つサーバーノードが新しいサブジェクト DN 属性を持つノードをクラスター ノードとして識別できるようにするには、実行中パラメータを新しいサブジェクト DN 属性に設定します。
そのためには、各サーバーの構成ファイルを変更して、新しい証明書のサブジェクト DN 属性を使用するようにtlsX509ClusterAuthDNOverride パラメータを設定します。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/10gen-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem" setParameter: tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB"
この構成は、各ノードを再起動するまで考慮されません。
すべてのメンバーを再起動します。
すべてのメンバーのローリング再起動を実行するには、各セカンダリを再起動し、次にプライマリを再起動します。
各 セカンダリ メンバー mongoshについて、 をメンバーに接続し、次の操作を行います。
ノードをシャットダウンするには、
db.shutdownServer()メソッドを使用します。use admin db.shutdownServer() ノードを再起動します。
次のセカンダリを再起動する前に、このノードが
SECONDARY状態に達していることを確認してください。メンバーの状態を判断するには、rs.status()を実行し、stateStrフィールドの値を読み取ります。rs.status().members
プライマリ メンバーの場合は、 mongoshをメンバーに接続し、次の操作を行います。
rs.stepDown()を使用してメンバーを降格します。rs.stepDown() ノードをシャットダウンするには、
db.shutdownServer()メソッドを使用します。use admin db.shutdownServer() ノードを再起動します。
レプリカセット内のすべてのサーバーが オーバーライド パラメーターを使用して、新しいサブジェクト DN 属性を持つ証明書を使用するノードからのピア接続を受け入れることができるようになりました。
すべてのノードの構成を変更します。
各サーバーの構成ファイルを更新します。
net.tls.certificateKeyFile設定を新しい証明書に変更します。net.tls.clusterFile設定を新しい証明書に変更します。古い証明書の DN 属性を使用するには、
tlsX509ClusterAuthDNOverrideパラメータを設定します。
以下に例を挙げます。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem" setParameter: tlsX509ClusterAuthDNOverride: "OU=10Gen Server,O=10Gen"
この構成は、各ノードを再起動するまで考慮されません。
すべてのメンバーを再起動します。
更新された構成を各メンバーに適用するには、ステップ 2 の手順を繰り返してサーバーノードのローリング再起動を実行します。
このプロセス中、新しい証明書で再起動されたノードは、 に保存されている古い DNtlsX509ClusterAuthDNOverride 属性を使用して、古い証明書を提示しているノードを識別します。まだ古い証明書を持っているノードは、 に保存されている新しい DNtlsX509ClusterAuthDNOverride を使用して、新しい証明書を提示するノードを識別します。
すべてのノードからオーバーライド パラメータを削除します。
更新されたサーバーノードが古い証明書を提示するクライアントをピアとして処理しないようにするには、すべてのサーバーノード構成ファイルから tlsX509ClusterAuthDNOverride パラメータを削除します。
以下に例を挙げます。
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
この構成は、各ノードを再起動するまで考慮されません。