Docs Menu

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に変更します。

1

各サーバーの構成ファイルを更新します。

  • 新しい証明書の 値を使用するには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 }
2

各セカンダリ クラスター ノードを再起動します。

  1. mongoshを使用して各セカンダリ クラスター メンバーに接続し、 db.shutdownServer()メソッドを使用してサーバーを停止します。

    use admin
    db.shutdownServer()
  2. サーバーを再起動します。

  3. メンバーの状態を判別するには、 rs.status()メソッドを使用します。

    rs.status().members
  4. このノードのstateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。

レプリカセット内のセカンダリ サーバーは、新しい DN 属性を持つ証明書を使用するノードからのピア接続を受け入れるようになりました。

3

プライマリ ノードを再起動します。

  1. mongoshを使用してプライマリに接続し、 rs.stepDown()メソッドを使用してノードをプライマリから降格します。

    rs.stepDown()

    クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。

  2. サーバーをシャットダウンするには、 db.shutdownServer()メソッドを使用します。

    use admin
    db.shutdownServer()
  3. サーバーを再起動します。

レプリカセット内のプライマリ サーバーが降格してセカンダリとして再起動し、新しい DN 属性を持つ証明書を使用するノードからのピア接続を受け入れるようになりました。

4

各サーバーの構成ファイルを更新します。

以下に例を挙げます。

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 }
5

各セカンダリ クラスター ノードを再起動します。

  1. mongoshを使用して各セカンダリ クラスター メンバーに接続し、 db.shutdownServer()メソッドを使用してサーバーを停止します。

    use admin
    db.shutdownServer()
  2. サーバーを再起動します。

  3. メンバーの状態を判別するには、 rs.status()メソッドを使用します。

    rs.status().members
  4. このノードのstateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。

レプリカセット内のセカンダリ サーバーが新しい X.509 証明書を使用するようになりました。

6

プライマリ ノードを再起動します。

  1. mongoshを使用してプライマリに接続し、 rs.stepDown()メソッドを使用してノードをプライマリから降格します。

    rs.stepDown()

    クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。

  2. サーバーをシャットダウンするには、 db.shutdownServer()メソッドを使用します。

    use admin
    db.shutdownServer()
  3. サーバーを再起動します。

レプリカセット内のプライマリ サーバーが降格し、新しい X.509 証明書を使用するセカンダリとして再起動します。

7

クラスターのすべてのノードが新しい 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

これにより、サーバーは起動時に古い証明書設定を構成しないようになります。

8

各セカンダリ クラスター ノードを再起動します。

  1. mongoshを使用して各セカンダリ クラスター メンバーに接続し、 db.shutdownServer()メソッドを使用してサーバーを停止します。

    use admin
    db.shutdownServer()
  2. サーバーを再起動します。

  3. メンバーの状態を判別するには、 rs.status()メソッドを使用します。

    rs.status().members
  4. このノードのstateStrフィールドにSECONDARYの値が表示されるまで待ってから、次のセカンダリを再起動します。

レプリカセット内のセカンダリ サーバーが再起動し、古い X.509 証明書からの接続を受け入れなくなります。

9

プライマリ ノードを再起動します。

  1. mongoshを使用してプライマリに接続し、 rs.stepDown()メソッドを使用してノードをプライマリから降格します。

    rs.stepDown()

    クラスターは、新しい証明書を持つセカンダリを、新しいプライマリとして機能するように昇格します。

  2. サーバーをシャットダウンするには、 db.shutdownServer()メソッドを使用します。

    use admin
    db.shutdownServer()
  3. サーバーを再起動します。

プライマリ サーバーが降格して再起動し、古い X.509 証明書からの接続を受け入れなくなります。