How does the server and client connect to the mongo db such that the communication between client--mongo and server--mongo is secure? Is this something meteor already takes care of or is it already default?
mongo enterprise supports ssl connections.
meteor does use mongo node driver which also supports ssl connections.
so if you want server <---> db connection to be secure, we need to enable ssl on the mongo instance and the driver.
to do so with a self signed certificate as instructed in https://docs.mongodb.com/manual/tutorial/configure-ssl/:
For testing purposes, you can generate a self-signed certificate and private key on a Unix system with a command that resembles the following:
openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key
Once you have the certificate, concatenate the certificate and private key to a .pem file, as in the following example:
cat mongodb-cert.key mongodb-cert.crt > mongodb.pem
and run mongod with...
mongod --sslMode requireSSL --sslPEMKeyFile
When setting up the Meteor environment variables for mongo db connections...
set...
MONGO_URL=mongodb://localhost:27017/?ssl=true
Related
I wanted to check the server certificate used by my AWS RDS postgres instance. I executed below command.
openssl s_client -connect <db_domain_name>:5432 -showcerts
It gave me the output below, which shows that the instance doesn't provide a certificate.
CONNECTED(00000003)
140121607600016:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
....
....
But if I try to connect to the database via psql, it shows me that it is using SSL.
psql (9.2.24, server 13.7)
WARNING: psql version 9.2, server version 13.0.
Some psql features might not work.
SSL connection (cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128)
Type "help" for help.
postgres=>
How does psql establish the SSL connection without server providing a certificate? If the server actually provides a certificate, why does openssl s_client fail to retrieve it?
I am trying to configure ssl/tls with mongod on ubuntu 20.04 LTS. mongod version is 5.0.5.
For generating ssl/tls, I am using ssl/ssl certificates from let's encrypt. I used this command for generating ssl/tls certificate.
sudo certbot certonly --standalone --preferred-challenges http -d example.domain.com
To configure it with mongod, I did the following steps
Copied fullchain.pem and privkey.pem file into a folder.
Use this command to generate mongodb.pem file for mongod.
cat privkey.pem fullchain.pem > mongodb.pem
For ca.pem ,I went to this URL, https://letsencrypt.org/certificates/ and downloaded Intermediate Certificates -> Active -> Let’s Encrypt R3 -> Signed by ISRG Root X1 (pem) file. Saved this file with name ca.pem in the same directory of fullchain.pem/privkey.pem files.
Verified certificate using this command. It returned mongodb.pem: OK
openssl verify -CAfile ca.crt mongodb.pem
Then I configure ssl/tls configuration with mongod, Added the following lines in /etc/mongod.conf
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /path/to/mongodb.pem
CAFile: /path/to/ca.pem
allowConnectionsWithoutCertificates: false
Restarted mongod service and It is running with active (running) status.
I am trying to connect to mongodb using the following command.
mongo --tls --tlsCAFile ca.pem --tlsCertificateKeyFile mongodb.pem --host mongodb.example-domain.com
But I am getting this error when I try to connect to mongodb using above command,
SSL peer certificate validation failed: unable to get issuer certificate
I don't know what I am doing wrong in the whole process. If anybody can help me in this ssl/tls certificate issue. Thanks
In the recent light of events of the MongoDB hacks. we too were hit by the hackers.
We enabled the authorization and changed the default port of the server.
However we want to encrypt our communication channel with the server with the help of a self signed certificate.
so our configuration looks like below
tls:
mode: requireTLS
allowConnectionsWithoutCertificates: false
certificateKeyFile: /etc/ssl/server.pem
CAFile: /etc/ssl/ca.crt
what happens is when I try to connect the mongoshell with the client certificate the connection is constantly denied. But after commenting the CAFile config and using --tlsAllowInavlidCertificates the connection is created.
I created the certificate with the following link:
https://gist.github.com/kevinadi/96090f6f9973ff8c2d019bbe0d9a0f70
To connect to the server I'm using the following command:
mongo --host hostname --username user --password password --authenticationDatabase admin --port port --tls --tlsCertificateKeyFile client.pem --tlsCAFile ca.crt
I dont know what I'm doing wrong and is this the correct way to do it even?
The server log contains reasons why connections are rejected.
Have generated the valid certificates from DigiCerts (CA file and the pem file) . PEM file is the combination of private key and server certificate. but somehow the mongo shell is not working with these certificates.
Here is the setup:
The environment :
what we have
Mongo server : Ubuntu 16.04 , mongo version : 4.0.10
have configured the /etc/mongod.conf file as well. mentioned the path of the Pem file and CA file correctly. the CN name matches the hostname and is exactly the same.
what is the issue
but now when i run the following mongo command , it fails
root#m1:/home/administrator# mongo --port 27017 --ssl --host m1.com –-sslPEMKeyFile /etc/pemfile.pem –-sslCAFile /etc/cafile.pem
MongoDB shell version v4.0.13 connecting to:
mongodb://m1.com:27017/%E2%80%93-sslPEMKeyFile?gssapiServiceName=mongodb
2019-12-05T06:50:31.195-0500 I NETWORK [js] DBClientConnection failed
to receive message from m1.com:27017 - SocketException: short read
2019-12-05T06:50:31.195-0500 E QUERY [js] Error: network error
while attempting to run command 'isMaster' on host 'm1.com:27017' :
connect#src/mongo/shell/mongo.js:344:17 #(connect):2:6 exception:
connect failed root#m1:/home/administrator#
the current server is primary/master server i guess.
please suggest
Finally found the solution on this. The actual issue was , not having Trusted root certificate in the CA file. CA file was having just DigiCert CA certificate but TrustedRoot certificate was missing.
The moment i added the certificate , it started working.
Thanks.
I Read through many documents in the mongoDB doc, still unclear how authentication works for clients an member of replica set(using x.509).
Found a resource "http://pe-kay.blogspot.in/2016/02/securing-mongodb-using-x509-certificate.html"
which was well documented, still not clear as how authentication happens.
Considering the below mongoConfig and commands for starting server and mongo client:-
mongoConfig.cfg
storage:
dbPath: "../DB"
security:
clusterAuthMode: x509
net:
port: 27001
ssl:
mode: "requireSSL"
PEMKeyFile: "../server/security/one.pem"
clusterFile: "../server/security/one.pem"
CAFile: "../server/security/rootCA.crt"
Commands in Prompt:-
cPrompt> mongod -v --config "../custom/mongoConf.cfg" --replSet "one"
cPrompt> mongo -ssl --sslPEMKeyFile "../client/security/oneHost.pem" --sslCAFile "../client/security/rootCA.crt" --host mylocalhost --port 27001
1) Is it a oneWay or a twoWay SSL/TLS ?
2) How authentication between members of replicaSet takes place (mongod - mongod while doing replication) and between server-client (mongod-mongo say mongoShell or application) ?
3) Which version of TLS is used ?
Can someone explain in detail ?
This is an old question, however I was facing the same issues and it took me a lot of time to get it working. Some items are rather essential but quite hidden in the documentation.
I try to give an overview without doing simple copy/paste from the MongoDB documentation.
In general a x.509 certificate in MongoDB provides these functions:
Generate keys to encrypt the connection
Ensure the connection is established from correct host (i.e. the declared hostname matches the actual hostname)
Authenticate a client (instead of using username + password or keyfile)
As starting point, one should have a look at these tutorials:
TLS/SSL Configuration for Clients
Configure mongod and mongos for TLS/SSL
Use x.509 Certificates to Authenticate Clients
Use x.509 Certificate for Membership Authentication
In general TLS/SSL settings are defined in this configuration file section:
net:
tls:
certificateKeyFile: server.pem
CAFile: server-ca.crt
clusterFile: member.pem
clusterCAFile: cluster-ca.crt
They correspond to command line options
--tlsCertificateKeyFile server.pem
--tlsCAFile server-ca.crt
--tlsClusterFile member.pem
--tlsClusterCAFile cluster-ca.crt
All other TLS/SSL related parameters are well documented and usually they should not cause any confusion or misunderstanding.
Step 1
When a client tries to establish a TLS/SSL enabled connection, then the mongod/mongos server presents a server certificate. The client verifies this certificate with a CA.
A client can be a normal client (e.g. the Mongo shell mongosh) or an internal Replica Set / Sharded Cluster member
The server certificate is always the same, mongod/mongos does not distinct the client types
The server certificate is defined by parameter
net.tls.certificateKeyFile or --tlsCertificateKeyFile
A normal client can verify the server certificate for example with these:
Option --tls --tlsCAFile server-ca.cer
Option --tls --tlsUseSystemCA
Connection string parameter tls=true&tlsCAFile=server-ca.cer
--tlsUseSystemCA exists only as option, you cannot define it in connection string. Would be like this:
mongosh --tlsUseSystemCA "mongodb://localhost/?tls=true"
An internal Replica Set / Sharded Cluster member verifies the server certificate by parameter
net.tls.CAFile or --tlsCAFile
If net.tls.CAFile or --tlsCAFile is not specified and you are not using x.509 authentication, the system-wide CA certificate store will be used. If you use x.509 authentication, then net.tls.CAFile or --tlsCAFile is required.
Step 2
The client presents a client certificate to the mongod/mongos server. The client certificate can be used to authenticate the user. In this case, you don't have to provide a password/keyfile.
For normal client, x.509 authentication is enabled by user creation, e.g.
db.getSiblingDB("$external").runCommand({createUser: "CN=myName,OU=myOrgUnit,O=myOrg,..."})
For Replica Set / Sharded Cluster member, x.509 authentication is enabled by parameter
security.clusterAuthMode: x509
A normal client (e.g. mongosh) provides client certificate for example by these parameters:
mongosh --tls --tlsCertificateKeyFile client.pem (no x.509 authentication)
mongosh --tls --authenticationDatabase $external --authenticationMechanism MONGODB-X509 --tlsCertificateKeyFile client.pem (with x.509 authentication)
mongosh "mongodb://username:secret#localhost/?tls=true&authSource=admin&tlsCertificateKeyFile=client.pem" (no x.509 authentication)
mongosh "mongodb://localhost/?tls=true&authSource=$exernal&tlsCertificateKeyFile=client.pem&authMechanism=MONGODB-X509" (with x.509 authentication)
An internal Replica Set / Sharded Cluster member provides member certificate by parameter net.tls.clusterFile or --tlsClusterFile
The monogd/mongos sever verifies the client/member certificate with Root-CA defined by parameter net.tls.clusterCAFile or --tlsClusterCAFile
The client can be a normal client (e.g. the Mongo shell mongosh) or an internal Replica Set / Sharded Cluster member
The Root-CA is always the same, mongos/mongod does not distinct between client certificate and member certificate
If net.tls.clusterCAFile or --tlsClusterCAFile is not defined, then net.tls.CAFile/--tlsCAFile is used for verification.
Pitfalls:
Some Mongo documents just refer to "client" certificate/connection. Be aware, this means normal clients (e.g. mongosh) as well as internal Replica Set / Sharded Cluster member clients. In this answer I use terms "client certificate" and "member certificate" for better understanding.
Server certificates and Member certificates must have the same O, OU, and DC in their subject name
Client certificates and Member certificates must have different O, OU, and DC in their subject name
Parameter pairs certificateKeyFile/CAFile and clusterFile/clusterCAFile are not used to separate connections from normal clients and connections from Replica Set / Sharded Cluster members. They are used to separate client and server certificates, i.e. incoming and outgoing connections. In my opinion, these names are totally miss-leading.
You can use a common Root-CA, defined by net.tls.CAFile
You can also use the same certificate for client, member and server. This common certificate can be even used for x.509 authentication of Replica Set / Sharded Cluster members. This certificate only provides encrypted connection and x.509 member authentication. Of course, you cannot use it for x.509 authentication of normal clients.
Option tlsAllowInvalidCertificates has no effect on x509 member authentication. For x509 authentication the certificate must be valid. Invalid certificates are only used to encrypt the connection.
Test cases:
openssl verify -CAfile server-ca.crt server.pem
openssl verify -CAfile cluster-ca.crt member.pem
openssl verify -CAfile cluster-ca.crt client.pem
openssl s_server -cert server.pem -CAfile cluster-ca.crt
# open another terminal
openssl s_client -cert member.pem -CAfile server-ca.crt -quiet -no_ign_eof -status <<< Q
openssl s_client -cert client.pem -CAfile server-ca.crt -quiet -no_ign_eof -status <<< Q
Visualization