Mongodb – How to authenticate mongodb server identity via mongodb shell

mongodb

I am trying to deploy a mongodb instance in my environment. I have settled a ssl connection so it is possible to authenticate clients (using a certificate they enter and agreed root ca by both the server and the client). Is there a way to authenticate the server identity too? (I could not find any reference to this issue)

I would like to use the mongo shell (without any side programming)

Thank you

Best Answer

I am trying to deploy a mongodb instance in my environment. I have settled a ssl connection so it is possible to authenticate clients (using a certificate they enter and agreed root ca by both the server and the client). Is there a way to authenticate the server identity too? (I could not find any reference to this issue) . I would like to use the mongo shell (without any side programming).

As per MongoDB documentation here MongoDB supports the following authentication mechanisms:

SCRAM (Default)
MongoDB Challenge and Response (MONGODB-CR) (Deprecated as of MongoDB 3.6)
x.509 Certificate Authentication.

New in version 2.6.

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 single certificate authority. You or your organization can generate and maintain an independent certificate authority, or use certificates generated by a third-party TLS/SSL vendor.

Client x.509 Certificates

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

Client Certificate Requirements

The client certificate must have the following properties:

A single Certificate Authority (CA) must issue the certificates for both the client and the server.
Client certificates must contain the following fields:

keyUsage = digitalSignature extendedKeyUsage = clientAuth
Each unique MongoDB user must have a unique certificate.
A client x.509 certificate’s subject, which contains the Distinguished Name (DN), must differ from that of a Member x.509 Certificate. Specifically, the subjects must differ with regards to at least one of the following attributes: Organization (O), the Organizational Unit (OU) or the Domain Component (DC).

WARNING If a client x.509 certificate’s subject has the same O, OU, and DC combination as the Member x.509 Certificate, the client will be identified as a cluster member and granted full permission on the system.

For your further ref here

Increase the connections allowed on the server

The total incoming connection limit on the server is determined by the lesser of the limits imposed by the operating system or maxIncomingConnections (aka maxConns in MongoDB 2.4 and earlier).

Typically Linux distributions limit file descriptors per process to 1024, of which MongoDB will use 80% for incoming connections (leaving about 819 available connections).

You can check current and available connections in the mongo shell via:

db.serverStatus().connections

For production systems it is typical to adjust the ulimit settings on Linux to allow more concurrent connections. For more best practices, I would recommend reviewing the Production Notes in the MongoDB manual.

Provide an API

If you are managing a shared server with resource limits, it is common to provide your own API rather than direct database access. This approach gives you an extra layer of abstraction so you can manage resource usage and server deployment independent of the client configuration. For example, you could move your database server or reconfigure from a standalone to a replica set, and the clients would not have to be aware of this. You can also manage custom resource limits (such as connections per client) via your API, based on the credentials the client uses to connect.

Reduce the connection pool size in the clients

MongoDB (as at 2.6) doesn't have an option to limit the connections per client. Normally client limits would be imposed via the driver (i.e. setting the connection pool size). For example, in the Java driver the MongoClient default maximum pool size is 100.

You've already suggested this isn't a desirable option as you don't want the clients to mess with the connection limits, but if you are going to impose a server side limit it would still be reasonable to have them set the pool size appropriately. Otherwise their applications will get frequent exceptions as you kill off excess connections.

Monitor client operations

If adjusting limits on the client or server isn't an option, an alternative to consider is implementing a script to count concurrent client connections (by IP) via db.currentOp() and kill excess connections via db.killOp(). You'd have to be very careful to only kill client requests. The killOp() command is a superuser command that will let you kill internal database threads as well (which can lead to unpredictable outcomes).

NOTE: This approach will be unsuccessful if your clients are connecting via a shared gateway (i.e. where the source IP does not uniquely identify a client).

MongoDB – Troubleshooting Issues with Self-Signed Certificates and SSL

The answer to my question comes from an article I found this afternoon and I completely understand what I was doing wrong before. http://demarcsek92.blogspot.com/2014/05/mongodb-ssl-setup.html

I'll explain a little more because of the suggestion from Markus.

Originally I was generating client and server key/certification pairs from a root CA that I had created. I was concatenating (adding) the other certificates that I was making to the root CA and using this as the input for --sslCAFile. The issue I was creating was using my server.pem key/cert for each node and then trying to pass the client.pem file to the server for validation which I found out throws the generic "Self signed certificate" error. Apparently it happens whenever invalid certs/keys are passed to the server to create a connection.

(I'm going to gloss over how to make the server/client key/cert as it is in the article and I would like people to go there for more explanation as it is this gentleman's solution and not my own.)

Create server.key and server.crt
Use "type server.key server.crt > server.pem" (for Windows)

Create client.key and client.crt
Use "type client.key client.crt > client.pem"

For the server the setup will be:
--sslPEMKeyFile = server.pem
--sslCAFile = client.pem

For the client the setup will be:
--sslPEMKeyFile = client.pem
--sslCAFile = server.pem

This solution, as is, works for a single node and single client connection. I was able to trace the line with Wireshark and see that Mongo had stopped identifying itself and that when I drilled down into the packets using the Follow TCP Stream option the only information it was exposing was part of the subject used in creating my certificates (ok behavior).

Find "Client Hello" transmission from Mongo by: Right-clicking on one of tranmission messages > Decode as... > Transport tab > SSL

On the "Client Hello" transmission from Mongo: Right-click the packet > Follow TCP Stream > You should see the packet encrypted

NEXT STEP: My next step is to figure out how to setup SSL certificates for a 3 node replica set. I'm still trying to wrap my head around creating certificates for each node and how they can all be linked so it will allow for each to trust each other and a client connection.

(I'm going to look into the Stack Exchange rules but I was just thinking about chaining to the next topic with a link in this one)