MongoDB and Let's Encrypt Certificates

Published Sep 3, 2018

Here's your quick guide to how connecting to MongoDB on Compose and IBM Cloud Compose is changing.

We're in the process of rolling out Let's Encrypt certificate support for our MongoDB deployments.

What does LE-enabled mean to my deployments?

When your IBM Cloud or Compose MongoDB is LE-enabled, it means that rather than having to save and present a self-signed certificate to verify that you are talking to the right server when you connect, you'll be able to let the Internet's verification mechanisms do that work for you.

That means that your applications can have simpler connection code and simpler code means more reliable code. But there's a change to go through to get there.

Here's the important things to know:

Your connection strings will change. The host names in connection strings will go from *.dblayer.com to *.composedb.com.
Your self-signed certificates will no longer be offered up in the UI, via Cloud Foundry VCAPs or in the API. This is because they are no longer needed.

Now a very important thing to know:

Your old connection strings with the self-signed certificate will continue to work. We aren't turning them off, just changing the presentation of connection strings, guiding you towards a new cleaner way to connect.

I have a deployment on Compose.com and have been using self-signed certificates...

Then you can continue to use them. Make sure that you have them recorded securely as the Compose console won't offer those details up when you are LE enabled.

So what should I do to my connection code?

Well, no two applications or drivers or languages are the same, but generally we recommend that you modify your application to take either a connection string with a certificate or just a connection string.

When there's no certificate available, assume that you are making a TLS/SSL connection which will automatically be verified using the LE certificates. If there is a self-signed certificate, assume you are making a TLS/SSL connection that needs that certificate to verify the server and present it as you have done in the past.

Your code will now be able to connect to either variation of connection strings.

I use Cloud Foundry on IBM Cloud

If you are using the VCAP services, just check for the presence of ca_certificate_base64. If its present, you have a self-signed certificate for your deployment and you should use that certificate when you do a TLS/SSL connection to the server. If the ca_certificate_base64 isn't present, then just use the connection strings to connect and the server verification will be handled for you.

I have a new deployment, what should I do?

If your connection strings are *.composedb.com then you can simply connect to the server with a TLS/SSL enabled connection and don't worry about verifying the server identity - that'll all be automatic.

I have Compose Enterprise, does this affect me?

No, Compose Enterprise deployments use self-signed certificates by design for all databases. You will not need to update your Compose Enterprise applications. If you wish to future-proof your applications so they run on Enterprise, Compose.com or IBM Cloud hosted databases, then modify your code as outlined above to handle when - and when there is not - a self-signed certificate available.

Updated Documentation

Updated Examples

~~attribution~~ Markus Spiske via Unsplash