Issue
I'm setting a replica set on 3 mongodb instances on debian 9 and I enabled TLS authentication for the replica set members. Here's the configuration :
security:
authorization: enabled
clusterAuthMode: x509
net:
tls:
mode: requireTLS
certificateKeyFile: crt-key.pem
CAFile: chain.crt
clusterFile: crt-key.pem
certificateKeyFilePassword: XXXXXX
clusterPassword: XXXXXX
allowConnectionsWithoutCertificates: true
replication:
replSetName: "my-replica-set"
The replication works fine but I can't connect with a username/password to the database :
mongosh --port 27017 --authenticationDatabase "admin" -u "user" -p
MongoServerSelectionError: connection <monitor> to 127.0.0.1:27017 closed
Here's the log :
{"t":{"$date":"2022-05-30T18:02:07.696+02:00"},"s":"I", "c":"NETWORK", "id":22988, "ctx":"conn30","msg":"Error receiving request from client. Ending connection from remote","attr":{"error":{"code":141,"codeName":"SSLHandshakeFailed","errmsg":"The server is configured to only allow SSL connections"},"remote":"127.0.0.1:46486","connectionId":30}}
Solution
net:
tls:
certificateKeyFile: crt-key.pem
clusterFile: crt-key.pem
is redundant. If clusterFile
is not provided then certificateKeyFile
is used. So, you can simply use
net:
tls:
mode: requireTLS
certificateKeyFile: crt-key.pem
CAFile: chain.crt
certificateKeyFilePassword: XXXXXX
allowConnectionsWithoutCertificates: true
mode: requireTLS
means, client and replicaset members have to use TLS/SSL, thus you must enable TLS/SSL also for client.
You need to specify tls option:
mongosh --tls --port 27017 --authenticationDatabase "admin" -u "user" -p
Depending on your openssl library version, you may also have to specify the CA-File, i.e.
mongosh --tls --tlsCAFile "chain.crt" --port 27017 --authenticationDatabase "admin" -u "user" -p
If you like to enable TLS/SSL only for replicaset members, then use
net:
tls:
mode: preferTLS
Now, you can connect with
mongosh --port 27017 --authenticationDatabase "admin" -u "user" -p
Note, depending on your CA this setup can be security risk. If chain.crt
is your own CA protected with your secret private key, then you are on the safe side. However, chain.crt
also could be a company wide, commonly used CA. In this case an attacker only needs to create an arbitrary certificate where the Organization attributes (O's), the Organizational Unit attributes (OU's), and the Domain Components (DC's) matches the crt-key.pem
and which is accepted by chain.crt
(which could be done by a simple ticket to your IT department).
Organization attributes (O's), the Organizational Unit attributes (OU's), and the Domain Components (DC's) of crt-key.pem
server certificate you get simply by
openssl s_client -showcerts -connect <hostname>:27017
Answered By - Wernfried Domscheit Answer Checked By - Timothy Miller (WPSolving Admin)