On this page
You can require that members of replica sets and sharded clusters authenticate to each other. For the internal authentication of the members, MongoDB can use either keyfiles or x.509 certificates.
The selected method is used for all internal communication. For example, when a
client authenticates to a
mongos using one of the supported
mongos then uses the configured internal authentication method to
connect to the required
Enabling internal authentication also enables client authorization.
Keyfiles use SCRAM challenge and response authentication mechanism where the keyfiles contain the shared password for the members.
A key's length must be between 6 and 1024 characters and may only
contain characters in the base64 set. MongoDB strips whitespace
x20) for cross-platform
convenience. As a result, the following operations produce identical
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
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.
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.
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.
|||For MongoDB's encrypted storage engine, the keyfile used for local key management can only contain a single key .|
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.
Members of a replica set or sharded cluster can use x.509 certificates for internal authentication instead of using keyfiles. MongoDB supports x.509 certificate authentication for use with a secure TLS/SSL connection.
MongoDB disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available. For more details, see Disable TLS 1.0.
Member Certificate Requirements
Member certificates which you use to verify membership to a sharded
cluster or a replica set (
net.tls.certificateKeyFile), must have the
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 (
the Organizational Unit (
the Domain Component (
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.certificateKeyFilecertificates for the other cluster members (or the
tlsX509ClusterAuthDNOverridevalue, 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
OUas well as the non-specification of the
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
OUattribute since one contains two
OUspecifications and the other, only one specification.
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 includes the Extended Key Usage (
extendedKeyUsage) setting, the value must include
clientAuth("TLS Web Client Authentication").
extendedKeyUsage = clientAuth
The x.509 certificate must not be expired.
Changed in version 4.4:
mongoslogs a warning on connection if the presented x.509 certificate expires within
30days of the
mongod/mongoshost system time. See x.509 Certificates Nearing Expiry Trigger Warnings for more information.
You can use TLS for internal authentication between each member of
your replica set (each
mongod instance) or sharded
To use TLS for internal authentication, use the following settings:
--tlsClusterFile(available starting in MongoDB 4.2)
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
(available starting in MongoDB 4.2).
To use the
certificate key file for both client authentication and
membership authentication, the certificate must either:
extendedKeyUsage = serverAuth, clientAuth
For an example of x.509 internal authentication, see Use x.509 Certificate for Membership Authentication.
To upgrade from keyfile internal authentication to x.509 internal authentication, see Upgrade from Keyfile Authentication to x.509 Authentication.