Internal/Membership Authentication

Key Requirements

A key's length must be between 6 and 1024 characters and may only contain characters in the base64 set. MongoDB strips whitespace characters (e.g. x0d, x09, and x20) for cross-platform convenience. As a result, the following operations produce identical keys:

echo -e "mysecretkey" > key1
echo -e "my secret key" > key1
echo -e "my secret key\n" > key2
echo -e "my    secret    key" > key3
echo -e "my\r\nsecret\r\nkey\r\n" > key4

Keyfile Format

Starting in MongoDB 4.2, keyfiles for internal membership authentication use YAML format to allow for multiple keys in a keyfile. The YAML format accepts either:

• A single key string (same as in earlier versions)

• A sequence of key strings

The YAML format is compatible with the existing single-key keyfiles that use the text file format.

For example,

The ability to specify multiple keys in a file allows for the rolling upgrade of the keys without downtime. See Rotate Keys for Replica Sets and Rotate Keys for Sharded Clusters.

All mongod and mongos instances of a deployment must share at least one common key.

On UNIX systems, the keyfile must not have group or world permissions. On Windows systems, keyfile permissions are not checked.

You must store the keyfile on each server hosting the member of the replica set or sharded clusters.

MongoDB Configuration for Keyfile

To specify the keyfile, use the security.keyFile setting or --keyFile command line option.

For an example of keyfile internal authentication, see Update Replica Set to Keyfile Authentication.

Member Certificate Requirements

Member certificates which you use to verify membership to a sharded cluster or a replica set (net.tls.clusterFile, if specified, and net.tls.certificateKeyFile), must have the following properties:

• A single Certificate Authority (CA) must issue all the x.509 certificates for the members of a sharded cluster or a replica set.

• The Distinguished Name (DN), found in the member certificate's subject, must specify a non-empty value for at least one of the following attributes:

  • the Organization (O)

  • the Organizational Unit (OU)

  • the Domain Component (DC)

• The Organization attributes (O's), the Organizational Unit attributes (OU's), and the Domain Components (DC's) must match those from both the net.tls.clusterFile and net.tls.certificateKeyFile certificates for the other cluster members (or the tlsX509ClusterAuthDNOverride value, if set).

  To match, the certificate must match all specifications of these attributes, even the non-specification of these attributes. The order of the attributes does not matter.

  In the following example, the two DN's contain matching specifications for O, OU as well as the non-specification of the DC attribute.

  CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
  C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

  However, the following two DN's contain a mismatch for the OU attribute since one contains two OU specifications and the other, only one specification.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• In multi-cluster deployments, each cluster must use a different X.509 member certificate. Each certificate must have unique values on the O, OU, and DC Distinguished Name (DN) fields.

  If two clusters have certificates with the same DN values, a compromised server on one cluster can authenticate as a member of the other.

• Either the Common Name (CN) or one of the Subject Alternative Name (SAN) entries must match the server hostname for other cluster members. Starting in MongoDB 4.2, when comparing SANs, MongoDB can compare either DNS names or IP addresses. In previous versions, MongoDB only compares DNS names.

  For example, the certificates for a cluster could have the following subjects:

  subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
  subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US

• If the certificate used as the certificateKeyFile includes extendedKeyUsage, the value must include both clientAuth ("TLS Web Client Authentication") and serverAuth ("TLS Web Server Authentication").

  extendedKeyUsage = clientAuth, serverAuth

• If the certificate used as the clusterFile includes extendedKeyUsage, the value must include clientAuth.

  extendedKeyUsage = clientAuth

• The x.509 certificate must not be expired.

  mongod / mongos logs a warning on connection if the presented x.509 certificate expires within 30 days of the mongod/mongos host system time. See x.509 Certificates Nearing Expiry Trigger Warnings for more information.

MongoDB Configuration

You can use TLS for internal authentication between each member of your replica set (each mongod instance) or sharded cluster (each mongod and mongos instance).

To use TLS for internal authentication, use the following settings:

• security.clusterAuthMode or --clusterAuthMode set to x509

• net.tls.clusterFile or --tlsClusterFile (available starting in MongoDB 4.2)

mongod and mongos instances use their certificate key file to prove their identity to clients, but it can also be used for membership authentication. If you do not specify a cluster file, members use their certificate key file for membership authentication. The certificate key file is the file you specify with net.tls.certificateKeyFile or --tlsCertificateKeyFile (available starting in MongoDB 4.2).

To use the certificate key file for both client authentication and membership authentication, the certificate must either:

• Omit extendedKeyUsage or

• Specify extendedKeyUsage = serverAuth, clientAuth