Set Up Self-Managed X.509 Authentication

On this page

Considerations

Prerequisites
Configure a Project to use a Public Key Infrastructure
Add a Database User using Self-Managed X.509 Authentication

Self-managed X.509 certificates provide database users access to the database deployments in your project. Database users are separate from Atlas users. Database users have access to MongoDB databases, while Atlas users have access to the Atlas application itself.

Considerations

If you enable LDAP authorization, you can't connect to your database deployments with users that authenticate with an Atlas-managed X.509 certificate.

After you enable LDAP authorization, you can connect to your database deployments with users that authenticate with an self-managed X.509 certificate. However, the user's Common Name in their X.509 certificate must match the Distinguished Name of a user who is authorized to access your database with LDAP.

You can have both users that authenticate with self-managed certificates and users that authenticate with Atlas-managed X.509 certificates in the same database.

Prerequisites

To use self-managed X.509 certificates, you must have a Public Key Infrastructure to integrate with MongoDB Atlas.

Configure a Project to use a Public Key Infrastructure

Turn on Self-Managed X.509 Authentication.

In the Security section of Atlas's left navigation panel, click Advanced.
Toggle Self-Managed X.509 Authentication to ON.

Provide a PEM-encoded Certificate Authority.

You can provide a Certificate Authority (CA) by:

Clicking Upload and selecting a .pem file from your filesystem.
Copying the contents of a .pem file into the provided text area.

You can concatenate multiple CAs in the same .pem file or in the text area. Users can authenticate with certificates generated by any of the provided CAs.

When you upload a CA, a project-level alert is automatically created to send a notification 30 days before the CA expires, repeating every 24 hours. You can view and edit this alert from Atlas's Alert Settings page. For more information on configuring alerts, see Configure Alert Settings.

Click Save.

To edit your CA once uploaded, click the Self-Managed X.509 Authentication Settings icon.

Add a Database User using Self-Managed X.509 Authentication

Open the Add New Database User dialog.

In the Security section of the left navigation, click Database Access. The Database Users tab displays.
Click Add New Database User.

Select CERTIFICATE.

Enter user information.

Field

Description

Distinguished Name

The user's Common Name (CN) and optionally additional Distinguished Name fields. For more information, see RFC 2253.

Example

CN=Jane Doe,O=MongoDB,C=US

User Privileges

You can assign roles in one of the following ways:

Select Atlas admin, which provides the user with readWriteAnyDatabase as well as a number of administrative privileges.
Select Read and write to any database, which provides the user with privileges to read and write to any database.
Select Only read any database which provides the user with privileges to read any database.
Select Select Custom Role to select a custom role previously created in Atlas. You can create custom roles for database users in cases where the built-in database user roles cannot describe the desired set of privileges. For more information on custom roles, see Configure Custom Database Roles.

Click Add Default Privileges. When you click this option, you can select individual roles and specify the database on which the roles apply. Optionally, for the read and readWrite roles, you can also specify a collection. If you do not specify a collection for read and readWrite, the role applies to all non-system collections in the database.

Note

The following table describes the Atlas specific privileges, the database it applies to, and the privilege actions they represent.

Atlas Specific Privilege	Database	Privilege Actions
`backup`	`admin`	`listDatabases` `listCollections` `listIndexes` `appendOplogNote` `getParameter` `serverStatus`
`clusterMonitor`	`admin`	`checkFreeMonitoringStatus` `connPoolStats` `getCmdLineOpts` `getDefaultRWConcern` `getLog` `getParameter` `getShardMap` `hostInfo` `inprog` `listDatabases` `listSessions` `listShards` `netstat` `replSetGetConfig` `replSetGetStatus` `serverStatus` `setFreeMonitoring` `shardingState` `top`
`dbAdmin`	User configured	`bypassDocumentValidation` `changeStream` `collMod` `collStats` `compact` `convertToCapped` `createCollection` `createIndex` `dbHash` `dbStats` `dropCollection` `dropDatabase` `dropIndex` `enableProfiler` `find` `killCursors` `listCollections` `listIndexes` `planCacheIndexFilter` `planCacheRead` `planCacheWrite` `reIndex` `renameCollectionSameDB` `storageDetails` `validate`
`dbAdminAnyDatabase`	User configured except `local` and `config`	`dbAdminAnyDatabase`
`enableSharding`		`enableSharding`
`read`	User configured	`changeStream` `collStats` `dbHash` `dbStats` `find` `killCursors` `listIndexes` `listCollections`
`readWrite`	User configured	`changeStream` `collStats` `convertToCapped` `createCollection` `dbHash` `dbStats` `dropCollection` `createIndex` `dropIndex` `find` `insert` `killCursors` `listIndexes` `listCollections` `remove` `renameCollectionSameDB` `update`
`killOpSession`	User configured	`inprog` `killop` `killAnySession` `listSessions`
`readWriteAnyDatabase`	User configured except `local` and `config`	`readWriteAnyDatabase` `changeStream` `collStats` `convertToCapped` `createCollection` `dbHash` `dbStats` `dropCollection` `createIndex` `dropIndex` `find` `insert` `killCursors` `listIndexes` `listCollections` `listDatabases` `remove` `renameCollectionSameDB` `update`
`readAnyDatabase`	User configured except `local` and `config`	`readAnyDatabase` `changeStream` `collStats` `dbHash` `dbStats` `find` `killCursors` `listIndexes` `listCollections` `listDatabases`

For information on the built-in Atlas privileges, see Built-in Roles.

For more information on authorization, see Role-Based Access Control and Built-in Roles in the MongoDB manual.

Click Add User.

← Configure User Authentication and Authorization with OneLogin VLDAP Encryption at Rest using Customer Key Management →