Info

Steps followed: 1. Create SSH tunnel to all 5 servers using following commands. start plink -N -pw %UnixPassword% -L 50021:mongohost1.mycompany.com:27017 %USERNAME%@mongohost1.mycompany.com start plink -N -pw %UnixPassword% -L 50022:mongohost2.mycompany.com:27017 %USERNAME%@mongohost2.mycompany.com start plink -N -pw %UnixPassword% -L 50023:mongohost3.mycompany.com:27017 %USERNAME%@mongohost3.mycompany.com start plink -N -pw %UnixPassword% -L 50024:mongohost4.mycompany.com:27017 %USERNAME%@mongohost4.mycompany.com start plink -N -pw %UnixPassword% -L 50025:mongohost5.mycompany.com:27017 %USERNAME%@mongohost5.mycompany.com 2. Use following command to connect to replica set. C:\Users\zendu>mongo -u myuser -p "mypassword" --authenticationDatabase mydb --ssl --sslCAFile C:\Users\zendu\Documents\certificates\UAT\mongodb\ca.pem --sslPEMKeyFile C:\Users\zendu\Documents\certificates\UAT\mongodb\qaserver.pem --sslPEMKeyPassword pempassword --sslAllowInvalidHostnames localhost:50021,localhost:50022,localhost:50023,localhost:50024,localhost:50025/mydb?replicaSet=RS_QA Mongo shell fails with following output MongoDB shell version v3.4.2 connecting to: mongodb://localhost:50021,localhost:50022,localhost:50023,localhost:50024,localhost:50025/dbgbcq1?replicaSet=RS_QA 2017-10-30T03:08:39.772-0700 I NETWORK [thread1] Starting new replica set monitor for RS_QA/localhost:50021,localhost:50022,localhost:50023,localhost:50024,localhost:50025 2017-10-30T03:08:40.577-0700 W NETWORK [thread1] The server certificate does not match the host name. Hostname: localhost does not match SAN(s): mongohost1.mycompany.com 2017-10-30T03:08:40.986-0700 W NETWORK [ReplicaSetMonitor-TaskExecutor-0] The server certificate does not match the host name. Hostname: localhost does not match SAN(s): mongohost2.mycompany.com 2017-10-30T03:08:41.909-0700 I NETWORK [ReplicaSetMonitor-TaskExecutor-0] changing hosts to RS_QA/mongohost1.mycompany.com:27017,mongohost2.mycompany.com:27017,mongohost3.mycompany.com:27017,mongohost4.mycompany.com:27017 from RS_QA/localhost:50021,localhost:50022,localhost:50023,localhost:50024,localhost:50025 2017-10-30T03:08:46.229-0700 W NETWORK [thread1] Failed to connect to 10.196.100.30:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:08:49.362-0700 W NETWORK [ReplicaSetMonitor-TaskExecutor-0] Failed to connect to 10.196.100.31:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:08:54.995-0700 W NETWORK [thread1] Failed to connect to 10.196.100.30:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:09:00.217-0700 W NETWORK [thread1] Failed to connect to 10.196.100.31:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:09:00.229-0700 W NETWORK [thread1] No primary detected for set RS_QA 2017-10-30T03:09:06.057-0700 W NETWORK [thread1] Failed to connect to 10.196.100.30:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:09:11.276-0700 W NETWORK [thread1] Failed to connect to 10.196.100.31:27017 after 5000ms milliseconds, giving up. 2017-10-30T03:09:11.288-0700 W NETWORK [thread1] No primary detected for set RS_QA 2017-10-30T03:09:11.306-0700 E QUERY [thread1] Error: could not find host matching read preference { mode: "primary", tags: [ {} ] } for set RS_QA : connect@src/mongo/shell/mongo.js:237:13 @(connect):1:6 exception: connect failed

Top User Comments

nick.brewer commented on Fri, 3 Aug 2018 18:33:29 +0000: I'm going to close this ticket, since the behavior demonstrated is by design; a connection string should contain the CN or SAN that is configured on the mongod. Regards, Nick nick.brewer commented on Thu, 14 Jun 2018 18:58:50 +0000: zendu, It looks like our troubleshooting of this issue fell through the cracks - sorry about that. If you're still seeing this behavior, I've done some testing that may be of use to you: In testing this, I've noticed that when connecting via an SSH tunnel, the /etc/hosts file on the mongod machine you're tunneling to needs to contain the address that matches the certificate for that machine. For example, in this test I ran: mongo --ssl --sslPEMKeyFile C:\Users\nick\Documents\mongodb.pem --sslAllowInvalidCertificates localhost:50021 The CentOS machine I SSH tunneled to needed to have the following in its /etc/hosts file: 198.51.100.5 mongodb.example.com Since you're not using the --host option to specify the hostnames that you're connecting to, they need to be determined from the system's hosts file to ensure that they match the CN or SAN fields in the certificate you're using. Additionally, as you can see from my previous example, the command to allow invalid certificates is actually --sslAllowInvalidCertificates, with an s at the end. Regards, Nick zendu commented on Thu, 22 Feb 2018 00:31:27 +0000: Mongo Shell on Windows does not recognize --sslAllowInvalidCertificate. I tried --sslAllowInvalidHostnames; but that does not help either. mark.agarunov commented on Mon, 30 Oct 2017 20:16:50 +0000: Hello zendu, Thank you for the report. Looking over the provided output, I believe the issue may be due to the hostname in the SSL certificate: 2017-10-30T03:08:40.577-0700 W NETWORK [thread1] The server certificate does not match the host name. Hostname: localhost does not match SAN(s): mongohost1.mycompany.com If the SSL certificate does not match the hostname provided in the connection string, the validation will fail.. To work around this, you can either add the --sslAllowInvalidCertificate to accept invalid certificates, or specify a hostname with --host which matches the SAN or CN field of the SSL certificate. Thanks, Mark

Steps to Reproduce