MongoDB Server accepting server certificate as client certificate

Question

I seem to be a bit confused regarding the x509 certificate authentication in MongoDB.

TLDR : I Created server- and client-certificates (signed by the same CA, but different CN and OU), created a user in the MongoDB using the subject name as username and successfully connected using the c# client + client certificates. With the MongoDB Compass I was able to connect to and read from the server, using the server certificates as client certificates. Why was I able to do authenticate using the wrong certificate? Is it not possible to control permissions on a per-certificate-basis?

Extended : I Created a Self-Signed Root-CA using OpenSSL, which signed another certificate which is my Signing-CA. Using this Signing-CA I created two more Certificates:

• Server certificate (CN=Server1,OU=Servers,O=project,ST=SH,C=DE)
• Client certificate (CN=Client1,OU=Clients,O=project,ST=SH,C=DE)

Having those certificates in place I started the MongoDB instance without authentication, initiated the replicaSet and created a user for the certificate using this command:

db.getSiblingDB("$external").runCommand({createUser: "CN=Client1,OU=Clients,O=project,ST=SH,C=DE",roles: [{role: "readWrite", db: "admin"}, {role: "userAdminAnyDatabase", db: "admin"}, {role: "clusterAdmin", db: "admin"}, {role: "root", db: "admin"}]}); . I restarded the server, this time using some more parameters to start with enabled authentication: --replSet *replicaSetName* --port *port* --dbpath *path* --logpath *path* --tlsMode requireTLS --clusterAuthMode x509 --tlsCAFile *path* --tlsCertificateKeyFile *path* --tlsClusterFile *path* --auth

I was able to connect without an issue using the C# client, the MongoDB Compass worked aswell. But when I tested other certificates to verify the security, I noticed that it was absolutely possible to use the server certificate and key file to connect to the server using the MongoDB compass. I Could not only connect, but browse and modify data aswell.

I was under the impression that every client certificate has to have an associated account in the $external database and thus only has the permissions/roles I assigned/granted to this specific user account.

Is this behavior supposed to be happening? Is it possible to create one user account per client-certificate and grant different permisisons on different databases?

Thanks for your attention and answers, have a good day!

Answer 1

It depends on how you have configured your mongod process. Assuming you have a configuration file for your mongod (default path is /etc/mongod.conf) you would look to see if you have net.tls and security.clusterAuthMode settings..

Example Configuration file with these settings:

storage:
  dbPath: /data/db
  journal:
    enabled: true
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
net:
  port: 27017
  bindIp: 0.0.0.0
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/node1.pem
    CAFile: /etc/ssl/ca.crt
    clusterFile: /etc/ssl/node1.pem
processManagement:
  fork: true
  pidFilePath: /var/run/mongodb/mongod.pid
  timeZoneInfo: /usr/share/zoneinfo
security:
  authorization: enabled
  clusterAuthMode: x509
replication:
  replSetName: replset

Other things

Recently MongoDB switched from SSL to TLS so depending on the version you are using you may find SSL instead of TLS .

Also, you might be using a replica set, or you might not be. If using a replica set you need to decide how a replica set member will authenticate to the other members. Should it use a keyfile, or should it use x509 as well as ordinary database users.

Also, you will need to create at least one named database user. The system will allow root access to the connected user if it is bound to localhost and no other users exist. This is called the localhost exception . Missing these steps is an incomplete and insecure installation.

Answer 2

Socket/TLS connection and authentication are separate steps in the high level connection establishment process.

The word "connection" is used by people to refer to multiple separate operations and processes and when troubleshooting any of these you need to be very clear about what it is you are looking at/asking about:

1. Socket connection from driver to server
2. Authentication by the driver (doesn't happen on monitoring connections which still go through the socket connection process)
3. Client object creation (not strictly a connection at all, though many people sloppily/erroneously use the word "connection" to refer to the action of creating a client object - creating a client object itself doesn't connect anything to anywhere)
4. Performing operations (even a server with authentication enabled permits one to create socket connections to it and execute operations like the ismaster command without authentication)

You probably are meaning to ask about #2 but you tested either #3 or #4, which as you should now see isn't necessarily giving you the expected results.

When TLS is enabled and "insecure TLS" isn't, the server will validate the client's TLS certificate (and the client will validate the server's) during the socket connection process. The certificate being validated must be signed by the CA that the validator is configured with. At this point there isn't anything preventing the client from supplying the server's certificate to the server, if you managed to give the client the private key that goes with the server's certificate (which normally shouldn't happen). The server warns about this situation in the logs. Note that no authentication has happened yet.

If you are using X.509 authentication (which must be configured on the client side and is separate from supplying certificates used for the socket connection, eg use the authMechanism URI option) then, after a successful socket connection and any associated certificate verification, the driver will perform the authentication. At this point you need to have the server user created that matches the distinguished name on the certificate.

MongoDB has guides for both setting up TLS connections and X.509 auth, read through them and follow them exactly as written and verify each step of the way.