Docs Menu
Docs Home
/
MongoDB Manual
/ / / /

Rolling Update of x.509 Certificates that Contain New DN on Self-Managed Clusters

Members of a replica set or a sharded cluster can use x.509 certificates for membership authentication to identify each other as memers of the same deployment.

To identify each others as members of the same deployment, the Organization attributes (O's), the Organizational Unit attributes (OU's), and the Domain Components (DC's) from the certificates must match.

In some situations, you may need to update the member certificates to new certificates with the new Distinguished Name (DN), such as if an organization changes its name. You can use the tlsX509ClusterAuthDNOverride parameter to set an alternative DN to use in matching. With this parameter, you can perform a rolling update of the certificates to new certificates with a different DN.

The following tutorial describes the process to update the certificates for a replica set without downtime.

Consider a replica set where each member's certificates (clusterFile and certificateKeyFile) with DN value that contains "OU=10gen Server,O=10gen" (additional attributes are not considered as part of the comparison):

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"

The following procedure updates the members' certificates (clusterFile and certificateKeyFile) to new certificates that have a DN value with "OU=MongoDB Server,O=MongoDB".

Note

The following procedure assumes that the new x.509 certificates meet membership certificate all other requirements. For details, see Member Certificate Requirements

The procedure requires that all members of the deployment be restarted. As the settings will not take into consideration until you restart all members, your instances may log messages until the procedure completes.

To avoid these messages, you can set the override parameter on running members.

Connect mongosh directly to each member of the deployment and set the tlsX509ClusterAuthDNOverride parameter to the new certificate DN:

db.adminCommand( { setParameter: 1, tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB" } )

Modify each member's configuration:

For example:

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=MongoDB Server,O=MongoDB"

The settings will not take into consideration until you restart each member (see next step).

Once you have modified the configuration for all the members, restart each secondary and then the primary.

For each secondary member, connect mongosh to the member and:

  1. Use the db.shutdownServer() method to shut down the member:

    use admin
    db.shutdownServer()
  2. Restart the member.

    Ensure the member has reached SECONDARY state before restarting the next secondary.

For the primary, connect mongosh to the member and

  1. Use rs.stepDown() to step down the member:

    rs.stepDown()
  2. Use the db.shutdownServer() method to shut down the member:

    use admin
    db.shutdownServer()
  3. Restart the member.

Once all the members have been restarted with the new certificate, you can remove the tlsX509ClusterAuthDNOverride parameter from the configuration.

For example:

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"

The settings will not take into consideration until you restart each member.

Back

Upgrade to x.509 from Keyfile