I've configured the mongodb using TLS/SSL certificates in the EC2 instance
The configuration looks as follows:
#ssl certificates
net:
tls:
mode: requireTLS
certificateKeyFile: /var/lib/mongo/cert/PEG.pem
CAFile: /var/lib/mongo/cert/peg.ca-bundle
security:
authorization: enabled
After configuring I'm trying to connect to mongo shell using the following command:
mongo domain.com --tls --tlsCertificateKeyFile /var/lib/mongo/cert/PEG.pem --tlsCAFile /var/lib/mongo/cert/peg.ca-bundle
But unable to enter into the shell and got the following error:
"error":"SSL peer certificate validation failed: unable to verify the first certificate"}}
Could anyone help how to approach this error
Thanks in Advance
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 am trying to configure the SSL certificates in MongoDB. For that, I took sample domain-name like myapptest.tk using freenom(online) and generated certificates for that domain-name using sslforfree(online). Assigned that domain-name to my MongoDB server IP in /etc/hosts file. After that Downloaded those certificates and configured them in /etc/mongod.conf file.
Here are my SSL configurations which I have used in mongod.conf
net:
port: 27017
bindIp: 0.0.0.0 # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6
addresses or, alternatively, use the net.bindIpAll setting.
ssl:
mode: requireSSL
PEMKeyFile: /etc/ssl/mongodb.pem
CAFile: /etc/ssl/ca_bundle.crt
allowConnectionsWithoutCertificates: false
allowInvalidHostnames: false
disabledProtocols: TLS1_0,TLS1_1
Here I am converting certificate.crt and private.key into mongodb.pem and passing as the value of PEMKeyFile and passing ca_bundle.crt as the value of CAFile. Finally restarted the mongod service using the command
sudo service mongod restart
mongodb server running successfully. Now I am trying to connect with mongodb server through the command
mongo --ssl --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca_bundle.crt --host myapptest.tk
I am unable to connect to the server. Getting the error like
MongoDB shell version v4.0.8
connecting to: mongodb://myapptest.tk:27017/?gssapiServiceName=mongodb
2019-04-04T19:57:40.401+0000 E NETWORK [js] SSL peer certificate validation failed: unable to get local issuer certificate
2019-04-04T19:57:40.402+0000 E QUERY [js] Error: couldn't connect to server myapptest.tk:27017, connection attempt failed: SSLHandshakeFailed: SSL peer certificate validation failed: unable to get local issuer certificate :
connect#src/mongo/shell/mongo.js:343:13
#(connect):2:6
exception: connect failed
If I am using the mongo command with the option --sslAllowInvalidCertificates like
mongo --ssl --sslAllowInvalidCertificates
I can able to connect with the mongodb server, otherwise, I was unable to connect with the server.
What's the wrong with configuring the SSL certificates in mongod.conf file?
what I want is, Can we able to connect with the MongoDB server with --sslCAFile?
How to generate the --sslPEMKeyfile and --sslCAFile in *.pem formats in mongodb?
Below was the link which I have followed:
https://docs.mongodb.com/manual/tutorial/configure-ssl/
Could anybody suggest me to achieve this?
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