Introduction

In today's digital world, keeping data safe is crucial. One of the ways databases like MongoDB ensure this safety is by using secure connections. The x.509 certificate is a tool that helps make these connections safe. When used with TLS/SSL, it makes sure both parties in the communication are genuine. This article will explain how MongoDB uses x.509 certificates with TLS/SSL to keep its connections secure.

In this article series, we will delve into:

• Understanding the fundamentals of TLS/SSL.
• Generating x.509 certificates using OpenSSL in docker container.
• Configuring MongoDB docker container instance with the x.509 certificate.
• Accessing a MongoDB instance secured with the x.509 certificate through Mongosh.

Understanding the fundamentals of TLS/SSL

The main goal of TLS/SSL is to provide privacy and data integrity between two communicating computer applications.

SSL is an older technology that contains some security flaws. Transport Layer Security (TLS) is the upgraded version of SSL that fixes existing SSL vulnerabilities. TLS authenticates more efficiently and continues to support encrypted communication channels.

When a connection is made, a "handshake" occurs. During this handshake, both parties agree on a version of the protocol, choose cryptographic algorithms, and authenticate each other (typically through certificates like x.509). This ensures the session is both confidential (due to encryption) and reliable (due to integrity checks).

Digital certificates, often based on the x.509 standard, play a crucial role in TLS/SSL. They are used to authenticate the identity of a website or server. Certificates are issued by trusted organizations called Certificate Authorities (CAs). For the purposes of our demonstration, we will employ OpenSSL to generate such a certificate

Generating x.509 certificates using OpenSSL in docker container.

When establishing a secure x.509 connection for MongoDB, there are specific steps and considerations to take into account:

• Docker Containerized Environment: We'll be leveraging Docker, a powerful tool that lets us create isolated, containerized environments. This ensures that our OpenSSL operations are consistent and easily reproducible across different platforms.

• OpenSSL and Self-Signed Certificates: OpenSSL is a robust toolkit for the TLS and SSL protocols. For our purposes, we'll use OpenSSL to produce a 'self-signed' certificate. While self-signed certificates offer encryption, they don't have the backing of a Certificate Authority (CA), which means they might not be suitable for production environments where trust verification is crucial.

• Key and Certificate Files: The certificate generation process will yield two main files:

  • A key file (*.key): This private key should be kept secret and is used for decryption.
  • Certificate Signing Request (CSR) file (*.csr): This file is a formal request to a Certificate Authority (CA) for a certificate. It contains information about the entity and the public key. While not directly used for the connection, the CSR is vital for generating the actual certificate, especially if you plan to get your certificate signed by a CA in the future.
  • A certificate file (*.crt): This public certificate contains the public key and can be shared. It’s what servers and clients will use to establish a mutual trust.

Docker Containerized Environment

Folder Structure

.
├── crt
└── Dockerfile

Dockerfile

• openssl added inside the custom ubuntu image

# Using the official Ubuntu 20.04 base Docker image
FROM ubuntu:20.04

# Maintainer information
LABEL maintainer="your name <email@example.com>"

# Ensure non-interactive setup (useful when installing packages)
ENV DEBIAN_FRONTEND=noninteractive

# Update packages and install required packages
RUN apt-get update && \
    apt-get install -y \
    wget \
    curl \
    build-essential \
    openssl \
    vim && \  
    apt-get clean

# Set the working directory
WORKDIR /app

# Command to run when the Docker container starts
CMD ["/bin/bash"]

docker image build and run docker container

• project "crt" folder mounted as volume

docker build -t ubuntu-custom .
docker run -it -v "$(pwd)/crt:/app/crt" --name ubuntu1 ubuntu-custom 

console output

root@182:/app# cd crt
root@182:/app/crt#

Certificate Authority (CA)

openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -days 3650 -subj '/CN=MyCA/OU=myOrgUnit/O=myOrg/L=myLocality/ST=myState/C=US' -out ca.crt

Generating the server x.509 Certificate files. Run commands below

openssl req -newkey rsa:2048 -days 3650 -nodes -subj '/CN=localhost/OU=myOrgUnit/O=myOrg/L=myLocality/ST=myState/C=US' -out server.csr -keyout server.key
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650 -extfile <(echo -e "keyUsage = digitalSignature, keyEncipherment\nextendedKeyUsage = serverAuth")
cat server.key server.crt > server.pem

Generating the client x.509 Certificate files. Run commands below

openssl req -newkey rsa:2048 -days 3650 -nodes -subj '/CN=x509user/OU=myOrgUnit/O=myOrg/L=myLocality/ST=myState/C=US' -out client.csr -keyout client.key
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650 -extfile <(echo -e "keyUsage = digitalSignature, keyEncipherment\nextendedKeyUsage = clientAuth")
cat client.key client.crt > client.pem

Revised folder structure after x.509 certificate production

.
├── crt
│   ├── ca.key
│   ├── ca.srl
│   ├── client.crt
│   ├── client.csr
│   ├── client.key
│   ├── server.crt
│   ├── server.csr
│   └── server.key
└── Dockerfile

Conclusion

In this article, we generated the mongodb-cert.key and mongodb.pem x.509 certificate files. We will be implementing these files into MongoDB in the next article here.

https://github.com/ozvaris/mongoDBx509.git