We are very happy to announce the new Robomongo with SSL support:
Robomongo 0.9.0 RC10!
In this new release, Robomongo supports almost all SSL options that can be configured with
mongo shell and Robomongo is probably the only MongoDB GUI program which can achieve this.
1. SSL Support
Robomongo (and MongoDB) supports TLS/SSL (Transport Layer Security/Secure Sockets Layer) to encrypt all of the network traffic. TLS/SSL ensures that network traffic is only readable by the trusted clients/servers.
Robomongo (and MongoDB) uses OpenSSL libraries. SSL encryption is done only with strong SSL ciphers with minimum of 128-bit key length for all connections.
Basic Connection to MongoDB with SSL Encryption
In order to connect to MongoDB server (mongod or mongos instance or MongoDB Atlas Cloud) which requires basic SSL encryption mode, configure a new Robomongo connection with “Address” (
--host i.e. “mongodb.hostname”) on Connection tab and “CA Certificate” (
--sslCAFile) on SSL tab to validate the server certificates as seen below:
With the configuration above Robomongo will connect to MongoDB server exactly like
mongo shell connects with the command below:
mongo --ssl --host mongodb.hostname --sslCAFile /etc/ssl/ca.pem
Connection to MongoDB that Requires Client Certificates
In order to connect to MongoDB server (mongod or mongos instance or MongoDB Atlas Cloud) that requires CA-signed client certificate (an SSL certificate signed by a certificate authority), we will use Robomongo SSL options “CA Certificate” and “PEM Cert/Key” (and “Passphrase” if PEM key is encrypted). An example can be seen below:
The configuration above is equivalent to mongo shell command line connection below:
mongo --ssl --host mongdb.hostname --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem
Using Advanced SSL Options
We have two advanced options, let’s firstly see them on Robomongo and then explain them one by one:
CRL File (Blocking Revoked Client Certificates)
In order to disallow client connections with revoked certificates, we use CRL (Certificate Revocation Lists) file (i.e. crl.pem) option on Robomongo. This file contains a list of revoked certificates. This option corresponds to
mongo --sslCRLFile option.
Mongo verifies that the hostname of MongoDB server – to which the connection attempted – matches the CN or SAN of the MongoDB’s PEM certificate file (
--sslPEMKeyFile). If the hostname does not match the CN/SAN, mongo will fail to connect. It is possible (although not advised) to disable this validation with this option. This option corresponds to
mongo --sslAllowInvalidHostnames option.
On Robomongo, we use “Invalid Hostnames” option to allow/disallow invalid host names.
Using Self-signed Certificates
Let’s start with an important suggestion from MongoDB documents for production uses of this option:
In general, avoid using self-signed certificates unless the network is trusted.
For production use, your MongoDB deployment should use valid certificates generated and signed by a single certificate authority.
Robomongo/MongoDB can use any valid SSL certificate issued by a certificate authority, or a self-signed certificate. If self-signed certificate is used, although the communications channel will be encrypted, there will be no validation of server identity. This configuration will prevent eavesdropping on the connection, however it will be vulnerable to a man-in-the-middle attack. Using a certificate signed by a trusted certificate authority will permit Robomongo/MongoDB to verify the server’s identity.
The example configuration above corresponds to mongo shell parameter below:
Troubleshooting SSL Connection Failures
Robomongo helps you with giving error details when SSL connection fails. This will save time since we will already have some idea about where to start investigation from.
Let’s explain this with a real example which can be seen below. Here we see the error is related to hostname mismatch; after a quick search (or even better, having read this blog), we find that mongo has a hostname validation feature. So we can start troubleshooting with learning more about MongoDB hostname validation rules. (Rule here is the hostname used in “Address” field on connection tab should be same as the hostname of the certificate used on SSL tab on Robomongo)
2. MongoDB Atlas Support
MongoDB Atlas is a cloud service for running, monitoring, and maintaining MongoDB deployments, including the provisioning of dedicated servers for the MongoDB instances.
After creating a new cluster on MongoD Atlas, you will be provided a similar connection string to connect your cluster:
mongo "mongodb://cluster0-shard-00-00-f8a5c.mongodb.net:27017,cluster0-shard-00-01-f8a5c.mongodb.net:27017,cluster0-shard-00-02-f8a5c.mongodb.net:27017/admin?replicaSet=Cluster0-shard-0" --ssl --username admin --password PASSWORD
In the Robomongo screenshot below, an example is shown which connects to single server in replica set:
Note: Currently Robomongo supports connection to single server of a replica set. Support for connection to Replica Sets is one of the most important features of next Robomongo release plan.
3. HighDPI Enhancements
In Robomongo RC10, for better High DPI support, we have implemented many fine-grained enhancements. And we have updated Robomongo to use latest Qt version Qt 5.7.
Some of the visible enhancements can be seen in the screenshot below.
For Windows, it can be seen that icons look much better and text layout is also better handled on new Robomongo 0.9.0 RC10.
We see that with Robomongo RC10 the improvement is huge.
Note: On Ubuntu 16.04, there is a known issue related to Qt on high DPI screens where the issue is more noticeable after changing “Scale for menu and title bars” on Ubuntu display menu. We will publish a quick “How to” blog to solve this problem.
4. Other Highlights from New Release
- For better security, we have updated our OpenSSL version to OpenSSL 1.0.1p which is the same version used by latest MongoDB 3.2.
- We have updated Qt from Qt 5.5 to latest Qt 5.7. With this update there are many enhancements including cross platform High DPI support.
Our next major priority is to complete support for the most popular features:
- SSH — Implemented
- TLS/SSL — Implemented
- Replica Sets — Planned for Next Release
- User Management — Planned for Next Release