The world is in a pandemic situation and I believe everyone doing good.
Please Stay Home! Stay Safe! In this situation, most of the people are doing WFH, and I believe its the right time to talk about how to enable the Developer, OPS Team, and DBA can initiate secure encrypted TCP connection instead of Plain TCP connection to the Database.
In this blog am going to discuss the below list of topics to get an ampler understanding of the X.509 Certificate and configuring MongoDB cluster to use TLS/SSL.
- What is the X.509 Certificate ?
- TLS/SSL Authentication
- Create a self-signed certificate for each replica-set member
- Create a self-signed certificate for mongo client / Driver
- Configure a Replica-Set to Support TLS/SSL
X.509 Certificate
Every time one talks about the X.509 certificate, people confused X.509 with TLS/SSL. Here I like to take a chance to give a little picture of the confusion.
- In cryptography, X.509 defines the format of Public Key Infrastructure certification
- TLS/SSL is an Application layer protocol
- TLS/SSL cryptographic protocols designed to provide communication security over a computer network
- Many TCP based protocols like HTTPS, SMTPS, FTPS, etc use TLS/SSL protocol.
X.509 Certificate In MongoDB
In MongoDB deployment, we can utilize the X.509 certificate in encrypting all MongoDB Traffic, User Authentication, and Internal Replica member authentication.
TLS/SSL Authentication Types:
After getting some clarity between X.509 and TLS/SSL, the next piece we need to understand SSL Authentication type.
One-Way TLS/SSL Authentication
In our day to day life, we are using One-way SSL Authentication in the way of accessing all websites running in HTTPS protocol(Banking, Social network, etc).
An important aspect of this authentication method is, Here client only validates/verify the server identity through the Certification Authority of the CA-signed public certificate shared by the server.
One-way SSL Auth
Mutual-Way TLS/SSL Authentication
In Mutual-Way SSL authentication, the server is authenticating itself to the client, and the client is authenticating itself to the server to establish a secure encrypted channel between them. Apart from a secure encrypted channel, it is all about ensuring that both parties involved in the communication are trusted.
Mutual-way SSL Auth
TLS/SSL Authentication in MongoDB
MongoDB only supports Mutual-way TLS/SSL Authentication, it helps to encrypt all of MongoDB’s network traffic. And TLS/SSL ensures that MongoDB transactions are only readable by the intended client.
Create a self-signed certificate for each replica-set member
Before proceeding to create the certificates we need to understand replica set architecture is very relevant. Therefore I have presented an example replica set below, based on that we will create the certificate and do the all required Mongod configuration.
All the details we will see below.
To use encryption, we need to create certificates for all the replica members and have a certification authority (CA) to signs them. Since having a certification authority can be pretty costly, we decide to use self-signed certificates.
To proceed with certificate generation we need to have OpenSSL installed on our system and certificates need to satisfy these requirements:
- All the replica member and client certificates need to be signed by the same CA.
- The common name (CN) required during the certificate creation must correspond to the hostname of the host.
- Any other field requested in the certificate creation should be a non-empty value and, hopefully, should reflect our organisation details.
- It is also very important that all the fields, except the CN, should match those from the certificates for the other cluster members.
TLS/SSL certificate validation toward Common Name or SAN
when the user attempting to connect a host using a TLS/SSL certificate, the FQDN or IP will be validated against Common Name or SAN Fields of the certificate. After the successful validation only, the connection will be established.
Create CA Private Certificate
Command:
we need to enter a strong password and save it in a secure vault. because using the example-ca.key and above entered password only we will sign other replica members certificates.
Sign CA Public Certificate
Command
This CA public certificate needs to share with all member certificate.
Generate the CSR and Private key for all member
For each replica member, we need to generate a CSR and Private Key. Finally, sign each CSR using the CA private key.
Remember: Fill out all the fields requested the same for each host, but remember to fill out a different common name (CN) that must correspond to the hostname.
Command
After generating the private key and CSR for each node. Now we need to sign all the all node CSR with CA Private key.
Signing CSR using CA Private & Public Key
Command
After sign each CSR, we will get one public key corresponding to that CSR. Then we need to concatenate respective replica member node private and public certificate to create a pem format file.
Once all the above step is completed, now we want to securely transport the respective node pem file and example-ca-pub.crt to respective replica member.
Create a self-signed certificate for mongo client / Driver
Here App server and DBA Team are clients for the Replica set, now we need to create a certificate for them.
Important things Remember for Client Certificate:
- Client certificates need to be signed by the same CA who signed all replica member certificate.
- Common name filed can enter wildcard name (*.example.com) or we can use the SAN field which allows multiple name entries on a single certificate.
- we need to specify a different value for O or OU filed compare to the replica set member certificate.
This one certificate helps to connect all the replica set members, so the common name must be a Wildcard name (*.example.com) or need to specify individual FQDN of each member of the replica set in Subject Alternative Name(SAN) field.
Create an example.conf file with the following content.
Once example.conf file has been created, create CSR file and private key to be used with a certificate with the following command:
Sign the client CSR using CA public and private key
Finally, you concatenate the key and the signed certificate.
We finished all certificate creation from client and replica set members. now it’s the time to configure the all replica set member mongod.conf
Configure a Replica-Set to Support SSL
We need to instruct mongod about the certificates to enable the encryption.
Change the configuration file /etc/mongod.conf on each host adding the following rows:
Restart the daemon
Now we are going to connect using mongo Client:
Configure a Replica-Set to Support TLS
TLS Mode support from MongoDB 4.2.
We need to instruct mongod about the certificates to enable the encryption.
Change the configuration file /etc/mongod.conf on each host adding the following rows:
Restart the daemon
Make sure to put the proper file names on each host (mongod1.pem on mongod1 host and so on).
Now, as long as we have made no mistakes, we have a properly configured replica set that is using encrypted connections.
Now we are going to connect using mongo Client:
Whatever mode TLS or SSL we are using, Make sure to put the proper file names on each host (mongod1.pem on mongod1.example.com host and so on)
Now, as long as we have made no mistakes, we have properly configured replica set that is using encrypted connections.
Everyone aware that certificate provides two things
1. Identity of host
2. Encryption.
But when we use a self-signed certificate it provides encryption but fails to provide the identity of the host. So always recommend our client to use CA-signed certificates in production.
Like you to enhance the security of your MongoDB servers our MongoDB engineers at Mydbops can provide the best services for you.