Distinguished name for MongoDB

Hi, just ran into this while trying to use Let's Encrypt issued certificates for MongoDB. MongoDB's documentation states that:

The Distinguished Name ( DN ), found in the member certificate's subject , must specify a non-empty value for at least one of the following attributes:

  • the Organization ( O )
  • the Organizational Unit ( OU )
  • the Domain Component ( DC )

I understand that Let's Encrypt CA cannot verify O or OU but is it possible to provide DC in some way. Otherwise, I'm at a loss on how to use Let's Encrypt CA issued certificates for my MongoDB deployment. I'm using certbot to automate my certificate issuance flow.

1 Like

I can't find such requirements in the MongoDB documentation? Can you post a link?

4 Likes

Here you go https://docs.mongodb.com/manual/tutorial/configure-x509-member-authentication/#certificate-requirements

2 Likes

Also found this thread on the MongoDB forums that talks about the same problem Let's Encrypt certificate for internal membership authentication - #3 by Alexey_Roshka - Ops and Admin - MongoDB Developer Community Forums

2 Likes

That page describes the certificate requirements necessary for membership authentication which is another way of saying client authentication. You don't need a publicly trusted certificate for that purpose. And while Let's Encrypt certificates can be used for client authentication in some circumstances, they are not generally intended for that purpose.

Sharded cluster members and replica set members can use x.509 certificates to verify their membership to the cluster or the replica set instead of using keyfiles. The membership authentication is an internal process.

This would be the appropriate portion of the documentation that could be used with Let's Encrypt certificates.

For production use, your MongoDB deployment should use valid certificates generated and signed by a certificate authority. You or your organization can generate and maintain an independent certificate authority, or use certificates generated by third-party TLS vendors. Obtaining and managing certificates is beyond the scope of this documentation.

6 Likes

Thanks for the information. My main goal is to have a secure MongoDB setup while automating the certificate management process for MongoDB. While I understand that Let's Encrypt certificates should not be used for client authentication, I see that certificates issued by Let's Encrypt do have extKeyUsage: clientAuth, serverAuth.

So my questions essentially boil down to (I understand that this might not be the best forum to ask these but any help would be greatly appreciated and be of great use to others that face a similar issue):

  1. If I use TLS in MongoDB only for server auth and use keyfile authentication for membership (internal) auth, does that mean that internal traffic between the members is unencrypted and hence insecure?
  2. If the answer to 1 is yes, then is my only solution to setup an internal PKI using something like step-ca to issue and renew self-signed certificates? The key thing here is not just issuing certs which can be done in a myriad of ways but also automating renewals and other certificate management tasks.
2 Likes

I don't know enough about MongoDB to answer the first question. But as for the second question, yes. Typically an internal CA is used to issue certificates that either have specialized requirements or that simply don't need to be publicly trusted. You can even take renewal automation out of the equation by simply making your cert lifetimes longer than the expected lifetime of the service.

1 Like

It's usually also perfectly possible to have a publicly trusted certificate at the server end and use an internal CA for user authentication. Frankly, IMO using a publicly trusted certificate for user authentication is not the proper way to do it anyway. You also wouldn't want to update your users certificates every 60-90 days :wink:

2 Likes

Thanks @rmbolger and @Osiris for all your help. Since my requirement is not to use these certificates for user authentication but internal authentication between servers within a MongoDB cluster (where 1 replica acts as a client and the other as a server), I will go ahead and setup an internal ACME server for our purposes. I've looked a the documentation of step-ca and it does not seem particularly difficult to configure and should integrate easily with my existing certbot setup as well.

2 Likes