-
Type:
Bug
-
Resolution: Works as Designed
-
Priority:
Minor - P4
-
None
-
Affects Version/s: 5.0.7
-
Component/s: Logging, Replication, Security
-
Labels:
-
Environment:5 servers, all Ubuntu 20.04 minimal, 2vcpu, 2Gb ram, 40Gb SSD disks, nothing running except MongoDB
-
ALL
-
-
Security 2022-06-13, Security 2022-06-27
In short
{{}}
I’ve created self-signed certificates for our 5-member MongoDB 5.0.7 replica set. I am only running the database, no actual clients (apart from other replica set members of course).
The replica set members can connect and everything seems to work, but we get some certificate related warnings to our logs during startup:
{{}}
Client isn't a mongod or mongos, but is connecting with a certificate with cluster membership
{{}}
{{}}
Client connecting with server's own TLS certificate
{{}}
and after startup, a..
Different user name was supplied to saslSupportedMechs
...log message on every authentication between replica set members.
About certificates
Each replset certificate has a certificate with distinct CN=db{nodenum} (eg. CN=db1) set in the certificate's subject field, along with shared values for organisation, organisation unit, address etc.
Each node also has /etc/hosts set with hostnames db1,db2,db3,db4,db5.
- I’ve also tried setting Subject Alt Names in certificates to reflect the same hostnames db1,db2,db3,db4,db5
- I’ve also tried installing separate certificates to be used as certificateKeyFile and clusterFile }}(with {{extendedKeyUsage set appropriately to serverAuth or clientAuth).
Our Mongo config for TLS and security is:{}{}
tls: mode: preferTLS certificateKeyFile: /etc/ssl/db1.pem # 2,3,4,5 for others clusterFile: /etc/ssl/cluster_db1.pem # 2,3,4,5 for others CAFile: /etc/ssl/ca.pem allowConnectionsWithoutCertificates: true security: authorization: enabled clusterAuthMode: x509
{{}}
{{}}
I can get the replica set to work with all of these variations, but I cannot get these certificate warnings to go away:
{{}}
{{
{"t":\{"$date":"2022-04-17T08:39:51.251+02:00"},"s":"W", "c":"ACCESS", "id":20430, "ctx":"conn19","msg":"Client isn't a mongod or mongos, but is connecting with a certificate with cluster membership"}}}
{{{"t":
{"$date":"2022-04-17T08:39:51.216+02:00"},"s":"W", "c":"NETWORK", "id":23236, "ctx":"conn11","msg":"Client connecting with server's own TLS certificate"}}}
When inspecting the log stream more closely:
{"t":{"$date":"2022-04-17T22:31:42.832+02:00"},"s":"I", "c":"REPL", "id":40440, "ctx":"initandlisten","msg":"Starting the TopologyVersionObserver"}
{"t":{"$date":"2022-04-17T22:31:42.832+02:00"},"s":"I", "c":"REPL", "id":40445, "ctx":"TopologyVersionObserver","msg":"Started TopologyVersionObserver"}
{"t":{"$date":"2022-04-17T22:31:42.833+02:00"},"s":"I", "c":"NETWORK", "id":23015, "ctx":"listener","msg":"Listening on","attr":{"address":"/tmp/mongodb-27017.sock"}} {"t":{"$date":"2022-04-17T22:31:42.833+02:00"},"s":"I", "c":"NETWORK", "id":23015, "ctx":"listener","msg":"Listening on","attr":{"address":"10.0.1.1"}}
{"t":{"$date":"2022-04-17T22:31:42.833+02:00"},"s":"I", "c":"NETWORK", "id":23015, "ctx":"listener","msg":"Listening on","attr":{"address":"127.0.0.1"}}
{"t":{"$date":"2022-04-17T22:31:42.833+02:00"},"s":"I", "c":"NETWORK", "id":23016, "ctx":"listener","msg":"Waiting for connections","attr":{"port":27017,"ssl":"on"}}
{"t":{"$date":"2022-04-17T22:31:42.833+02:00"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener","msg":"Connection accepted","attr":{"remote":"10.0.1.1:57554","connectionId":2,"connectionCount":1}}
{"t":{"$date":"2022-04-17T22:31:42.851+02:00"},"s":"W", "c":"NETWORK", "id":23236, "ctx":"conn2","msg":"Client connecting with server's own TLS certificate"}
{"t":{"$date":"2022-04-17T22:31:42.852+02:00"},"s":"I", "c":"ACCESS", "id":5286202, "ctx":"conn2","msg":"Different user name was supplied to saslSupportedMechs","attr":{"error":{"code":17,"codeName" :"ProtocolError","errmsg":"Attempt to switch database target during SASL authentication."}}}
{"t":{"$date":"2022-04-17T22:31:42.852+02:00"},"s":"W", "c":"ACCESS", "id":20430, "ctx":"conn2","msg":"Client isn't a mongod or mongos, but is connecting with a certificate with cluster membership "}
{"t":{"$date":"2022-04-17T22:31:42.852+02:00"},"s":"I", "c":"ACCESS", "id":20429, "ctx":"conn2","msg":"Successfully authenticated","attr":{"client":"10.0.1.1:57554","mechanism":"MONGODB-X509","use r":"CN=db1,OU=MONGO_CLUSTER,O=MY_ORG,L=MY_CITY,ST=MY_STATE,C=MY_COUNTRY","db":"$external"}}
{"t":{"$date":"2022-04-17T22:31:42.853+02:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn2","msg":"Connection ended","attr":{"remote":"10.0.1.1:57554","connectionId":2,"connectionCount":0}}
...and to me it seems that the db1 (in this case) is connecting with itself, and then complaining about a client (itself?) using the server's own certificate for authenticating, and then complaining about the client not being a mongod or mongos (which it definitely is). All very confusing for this less educated MongoDB user.
Possibly relevant
After the initial startup, we also get a constant stream of these log messages (always in this order)
{"t":{"$date":"2022-04-18T09:33:20.115+02:00"},"s":"I", "c":"ACCESS", "id":5286202, "ctx":"conn45","msg":"Different user name was supplied to saslSupportedMechs","attr":{"error":{"code":17,"codeName":"ProtocolError","errmsg":"Attempt to switch database target during SASL authentication."}}}
{"t":{"$date":"2022-04-18T09:33:20.116+02:00"},"s":"I", "c":"ACCESS", "id":20429, "ctx":"conn45","msg":"Successfully authenticated","attr":{"client":"10.0.1.5:53270","mechanism":"MONGODB-X509","user":"CN=db5,OU=MONGO_CLUSTER,O=MY_ORG,L=MY_CITY,ST=MY_STATE,C=US","db":"$external"}}
...I have no idea whether they are related to the certificate warning or not, and if they should be dealt with somehow. It would perhaps help understanding what is going on, if the log message also shared details about the relevant databases and user names?
Anyway, any help in shedding some light to this would be much appreciated, bug or not.
{}{}
