Docs Menu

Docs Home → Develop Applications → MongoDB Manual

x.509

On this page

  • Certificate Authority
  • Client x.509 Certificates
  • Member x.509 Certificates

MongoDB supports x.509 certificate authentication for client authentication and internal authentication of the members of replica sets and sharded clusters.

x.509 certificate authentication requires a secure TLS/SSL connection.

Certificate Authority

For production use, your MongoDB deployment should use valid certificates generated and signed by a certificate authority. You or your organization can generate and maintain an independent certificate authority, or use certificates generated by third-party TLS vendors. Obtaining and managing certificates is beyond the scope of this documentation.

Client x.509 Certificates

To authenticate to servers, clients can use x.509 certificates instead of usernames and passwords.

Client Certificate Requirements

Client certificate requirements:

  • A single Certificate Authority (CA) must issue the certificates for both the client and the server.

  • Each unique MongoDB user must have a unique certificate.

  • The x.509 certificate must not be expired.

    Note

    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.

  • Client certificates must contain the following fields:

    keyUsage = digitalSignature
    extendedKeyUsage = clientAuth

  • At least one of the following client certificate attributes must be different than the attributes in both the net.tls.clusterFile and net.tls.certificateKeyFile server certificates:

    • Organization (O)

    • Organizational Unit (OU)

    • Domain Component (DC)

    Note

    You can also disable the enforceUserClusterSeparation parameter during startup to automatically disable the O/OU/DC check. This allows member certificates to authenticate as users stored in the $external database.

  • The subject of a client x.509 certificate, which contains the Distinguished Name (DN), must be different than the subjects of member x.509 certificates.

    Important

    If a client x.509 certificate's subject matches the O, OU, and DC attributes of the Member x.509 Certificate (or tlsX509ClusterAuthDNOverride, if set) exactly, the client connection is accepted, full permissions are granted, and a warning message appears in the log.

    Only cluster member x509 certificates should use the same O, OU, and DC attribute combinations.

    New in version 4.2: If the MongoDB deployment has tlsX509ClusterAuthDNOverride set, the client x.509 certificate's subject must not match that value.

MongoDB User and $external Database

To authenticate with a client certificate, you must first add the client certificate's subject as a MongoDB user in the $external database. The $external database is the Authentication Database for the user.

Each unique x.509 client certificate is for one MongoDB user. You cannot use a single client certificate to authenticate more than one MongoDB user.

To use Client Sessions and Causal Consistency Guarantees with $external authentication users (Kerberos, LDAP, or x.509 users), usernames cannot be greater than 10k bytes.

TLS Connection X509 Certificate Startup Warning

Starting in MongoDB 5.0, mongod and mongos now issue a startup warning when their certificates do not include a Subject Alternative Name attribute.

The following platforms do not support common name validation:

  • iOS 13 and higher

  • MacOS 10.15 and higher

  • Go 1.15 and higher

Clients using these platforms will not authenticate to MongoDB servers that use x.509 certificates whose hostnames are specified by CommonName attributes.

Member x.509 Certificates

For internal authentication between members of sharded clusters and replica sets, you can use x.509 certificates instead of keyfiles.

Member Certificate Requirements

Use member certificates to verify membership to a sharded cluster or a replica set. Member certificate file paths are configured with the net.tls.clusterFile and net.tls.certificateKeyFile options. Members have the following configuration requirements:

  • Cluster member configuration must specify a non-empty value for at least one of the attributes used for authentication. By default, MongoDB accepts:

    • the Organization (O)

    • the Organizational Unit (OU)

    • the Domain Component (DC)

    You can specify alternative attributes to use for authentication by setting net.tls.clusterAuthX509.extensionValue.

  • Cluster member configuration must include the same net.tls.clusterAuthX509.attributes and use matching values. Attribute order doesn't matter. The following example sets O and OU, but not DC:

    net:
      tls:
        clusterAuthX509:
          attributes: O=MongoDB, OU=MongoDB Server

Note

If you disable the enforceUserClusterSeparation parameter, the following behaviors apply:

  • The O/OU/DC check is disabled if clusterAuthMode is keyFile in your configuration file. This allows clients possessing member certificates to authenticate as users stored in the $external database.

  • The server won't start if clusterAuthMode isn't keyFile in your configuration file.

If you set the enforceUserClusterSeparation parameter to false, the server doesn't distinguish between client certificates, which applications use to authenticate, and intra-cluster certificates, which have privileged access. This has no effect if your clusterAuthMode is keyFile. However, if your clusterAuthMode is x509, user certificates that use the allowed scheme are conflated with cluster certificates and granted privileged access.

Your existing certificates are granted internal privileges if you do the following:

  1. Create a user, with a name allowed by this parameter.

  2. Set the enforceUserClusterSeparation parameter to false.

  3. Set clusterAuthMode to x509.

You must not upgrade from keyFile to x509 without validating that you've removed users with elevated privileges that the enforceUserClusterSeparation flag allowed you to create.

To set the enforceUserClusterSeparation parameter to false, run the following command during startup:

mongod --setParameter enforceUserClusterSeparation=false

The certificates have the following requirements:

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

  • At least one of the Subject Alternative Name (SAN) entries must match the server hostname used by other cluster members. When comparing SANs, MongoDB can compare either DNS names or IP addresses.

    If you don't specify subjectAltName, MongoDB compares the Common Name (CN) instead. However, this usage of CN is deprecated per RFC2818

  • 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

MongoDB Configuration for Membership Authentication

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:

mongod and mongos instances use their certificate key files to prove their identity to clients, but certificate key files can also be used for membership authentication. If you do not specify a cluster file, members use their certificate key files for membership authentication. Specify the certificate key file 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

← Use SCRAM to Authenticate Clients
Use x.509 Certificates to Authenticate Clients →

On this page