2

Trying to set up a 3 node mongodb server replica on Ubuntu 18.04, mongo version 4.0.18

gl1 192.168.1.30
gl2 192.168.1.31
gl3 192.168.1.33

Using an internal CA on the same network to create certs, I have created 2 certs, one for the server mongo is installed on (GL1, GL2, GL3) for PEMKeyFile and one for the clusterFile (mongo1, mongo2, mongo3). Each CAFile is set listing the respective RSA key, PEMKeyFile and RootCA for each server. I have mongo services running (according to systemctl) fine using the individual certs (PEMKey and clusterFILE).

net:
  port: 27017
  bindIp: 0.0.0.0
net:
 ssl:
  mode: requireSSL
  PEMKeyFile: /opt/ssl/MongoDB.pem
  CAFile: /opt/ssl/ca.pem
  clusterFile: /opt/ssl/mongo.pem
  allowConnectionsWithoutCertificates: true

#replication
replication:
  replSetName: rs0

Getting the following error when I try to rs.add("192.168.1.31:27017") I get the following error

 "errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 192.168.1.30:27017; the following nodes did not respond affirmatively: gl2.domain.com:27017 failed with stream truncated",
        "code" : 74,
        "codeName" : "NodeNotFound",

In the mongod.log on node 192.168.1.31 the following is logged:

2020-05-22T18:20:48.161+0000 E NETWORK  [conn4] SSL peer certificate validation failed: unsupported certificate purpose
2020-05-22T18:20:48.161+0000 I NETWORK  [conn4] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 192.168.1.30:55002 (connection id: 4)

I have read on an old Google groups post: https://groups.google.com/forum/#!msg/mongodb-user/EmESxx5KK9Q/xH6Ul7fTBQAJ that the clusterFile and PEMKeyFile had to be different. However, I did that and it still is throwing errors. I have done a lot of searching on this and I'm seeing much to support that this how it's done, but it is the only place I've found that has a similar error message and it seems logical that it should work. However, I'm not sure how I can verify that my clusterFile is actually being used. It is indeed a separate certificate with a FQDN for each node. All three nodes have host files updated to find each other (gl1, mongo1, etc). I can ping all nodes between themselves, so networking is up. I've also verified the firewall (ufw and iptables) is not blocking 27017 or anything at this point. Previously I tried the self-signed CA and certs but kept running into errors since those were self signed certs, so that is why I went the internal CA route.

bradgino
  • 23
  • 3

1 Answers1

3

The "purpose" is also known as "extended key usage".

Openssl x509v3 Extended Key Usage gives some example code for setting the purposes.

As pointed out by Joe, the documentation states that the certificates must either have no extended key usage at all, or the one in the PEMKeyFile must have server auth, and the one in the cluster file must have client auth.

D. SM
  • 13,584
  • 3
  • 12
  • 21
  • 1
    see https://docs.mongodb.com/manual/tutorial/configure-x509-member-authentication/index.html#use-x-509-certificate-for-membership-authentication - the certificates must either have no extended key usage at all, or the one in the PEMKeyFile must have server auth, and the one in the cluster file must have client auth. – Joe May 22 '20 at 22:03