[SERVER-35587] Cannot connect to MongoDB using SSH tunnel and SSL Created: 30/Oct/17 Updated: 27/Oct/23 Resolved: 03/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Shell |
| Affects Version/s: | 3.4.9 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Zendu | Assignee: | Nick Brewer |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Client - MongoDB v3.4.2 on Windows 10 64 bit |
||
| Participants: |
| Description |
|
Steps followed:
2. Use following command to connect to replica set.
Mongo shell fails with following output
|
| Comments |
| Comment by Nick Brewer [ 03/Aug/18 ] | ||
|
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
| ||
| Comment by Nick Brewer [ 14/Jun/18 ] | ||
|
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:
The CentOS machine I SSH tunneled to needed to have the following in its /etc/hosts file:
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, | ||
| Comment by Zendu [ 22/Feb/18 ] | ||
|
Mongo Shell on Windows does not recognize --sslAllowInvalidCertificate. I tried --sslAllowInvalidHostnames; but that does not help either. | ||
| Comment by Mark Agarunov [ 30/Oct/17 ] | ||
|
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:
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, |