ilustración de MongoDB replica set con TLS/SSL
ilustración de MongoDB replica set con TLS/SSL

Configuración de un replica-set en MongoDB con TLS/SSL

La seguridad en MongoDB ha evolucionado de forma notable en los últimos años. Hoy en día, cualquier despliegue profesional —especialmente en entornos de producción o con replicación— debería utilizar TLS/SSL para cifrar el tráfico y autenticar los nodos del clúster.

En este artículo repasamos:

  • Qué tipos de certificados utiliza MongoDB
  • Qué modos de conectividad TLS admite
  • Cómo generar una CA, certificados de servidor y certificados de cliente para preparar un replica set para trabajar con TLS/mTLS

¿Qué es TLS/SSL y el certificado X.509?

Es frecuente que, cuando hablamos de certificados y de TLS, se mezclen conceptos. Por eso, antes de ver un ejemplo de cómo configurar MongoDB para usar TLS/SSL, revisemos estas bases.

TLS (Transport Layer Security) garantiza tres propiedades esenciales:

  1. Cifrado del tráfico: evita que terceros puedan leer datos en tránsito entre clientes y servidores.
  2. Autenticación: permite verificar que el servidor es quien dice ser mediante un certificado firmado por una CA confiable.
  3. Integridad: impide que un atacante pueda modificar datos en tránsito sin ser detectado. En un replica set, además, TLS protege la comunicación interna entre nodos (primary, secondary y arbiter).

Es decir, TLS/SSL es un protocolo criptográfico de capa de aplicación, diseñado para proporcionar seguridad en las comunicaciones a través de una red informática. Pensemos, por ejemplo, en protocolos como HTTPS, SMTPS o FTPS, que utilizan TLS/SSL.

Sin embargo, un certificado X.509 define el formato de certificación de infraestructura de clave pública que se utiliza para identificar de forma segura a personas, servidores, servicios o dispositivos dentro de una red. Es la base de la seguridad en TLS/SSL, VPN, autenticación mutua, firmas digitales y, prácticamente, todo lo que implica criptografía moderna en Internet.

Tipos de autenticación TLS/SSL

Una vez que ya sabemos que queremos cifrar nuestro tráfico, tenemos que decidir el tipo de autenticación a usar, y aquí entra en juego el protocolo TLS/SSL.

Principalmente encontramos dos tipos:

  • Autenticación TLS/SSL unidireccional.

En nuestro día a día, utilizamos la autenticación SSL unidireccional para acceder a todos los sitios web que utilizan el protocolo HTTPS (bancos, redes sociales, etc.). Un aspecto importante de este método de autenticación es que el cliente solo valida o verifica la identidad del servidor mediante la autoridad de certificación del certificado público firmado por la CA y compartido por el servidor.

Intercambio de certificados TLS entre cliente y servidor
  • Autenticación TLS/SSL de vía mutua (mTLS).

En la autenticación SSL de vía mutua, el servidor se autentica ante el cliente y este se autentica ante el servidor para establecer un canal cifrado seguro entre ambos. Además de un canal cifrado seguro, se trata de garantizar la confianza de ambas partes en la comunicación. MongoDB utiliza este tipo de autenticación.

Intercambio de certificados mTLS entre cliente y servidor

Tipos de certificados que utiliza MongoDB

Si pensamos en una implementación de MongoDB (replica set), podemos utilizar el certificado X.509 para cifrar todo el tráfico de MongoDB, la autenticación de usuarios y la autenticación de miembros de la réplica interna.

MongoDB trabaja con tres tipos de certificados X.509 estándar:

1- Certificado de CA (Certificate Authority)

Es la autoridad que firma los certificados del resto de nodos.

Puede ser:

  • Una CA interna (OpenSSL)
  • Una CA corporativa
  • Una CA pública (menos habitual en entornos internos)

MongoDB solo necesita el certificado público de la CA (ca.pem)

2- Certificados de servidor

Cada nodo del replica set debe tener su propio certificado, que incluye:

  • Clave privada (.key)
  • Certificado firmado (.crt)
  • Archivo combinado (.pem) → MongoDB exige este formato

Certificados de cliente (para mTLS)

Son opcionales, pero recomendados cuando se quiere:

  • Autenticar clientes mediante certificados X.509
  • Evitar accesos no autorizados incluso antes de la autenticación interna de MongoDB

El cliente también debe tener un archivo (`.pem`) que combine clave privada y certificado.

Configuración de MongoDB para soportar TLS/SSL

Una vez vistos los distintos elementos y con los conceptos más claros, vamos a revisar el procedimiento para configurar un replica set de MongoDB habilitando TLS/SSL.

El siguiente procedimiento asumimos que tenemos los tres nodos del replica-set en tres servidores independientes (mongoserver1, mongoserver2, mongoserver3) y que ya hemos inicializado nuestro replicaset (rs-prueba)

1) Crear la CA

El certificado raíz (conocido como archivo CA) se utilizará para firmar e identificar su certificado.

En este caso se añade el operador -sub para proporcionar los detalles de nuestra organización.

#Crear un directorio temporal para guardar los certificados

$ mkdir -p mongo-tls
$ cd mongo-tls

#Creamos el certificado para la CA
openssl req -nodes -new -x509 \

  • days 3650 \
  • keyout ca.key \
  • out ca.pem \
  • subj

«/C=ES/ST=Madrid/L=Madrid/O=Pruebas/OU=mongoPruebas/CN=mongoserver1, mongoserver2, mongoserver3»

Prestar atención al CN (Common Name), ya que MongoDB obliga a poner el hostname. En este caso, al tener tres nodos, ponemos el nombre de los tres nodos.

2) Generar las solicitudes de certificado (CSR) y las claves privadas

En este proceso se crean los Certificate Requests y las claves privadas para cada nodo que compone el replicaset.

$ openssl req -nodes -newkey rsa:4096 -sha256 \

  -keyout mongodbserver1.key \

  -out mongodbserver1.csr \

  -subj «/C=ES/ST=Madrid/L=Madrid/O=Pruebas/OU=mongoPruebas/CN=mongoserver1»

$ openssl req -nodes -newkey rsa:4096 -sha256 \

  -keyout mongodbserver1.key \

  -out mongodbserver2.csr \

«/C=ES/ST=Madrid/L=Madrid/O=Pruebas/OU=mongoPruebas/CN=mongoserver2»

$ openssl req -nodes -newkey rsa:4096 -sha256 \

  -keyout mongodbserver1.key \

  -out mongodbserver3.csr \

  -subj «/C=ES/ST=Madrid/L=Madrid/O=Pruebas/OU=mongoPruebas/CN=mongoserver3»

Prestar atención a que, en este caso, el CN se corresponde con el nombre del hostname.

3) Firmar los certificados con la CA

Usamos el archivo CA (ca.pem) y su clave privada (ca.key) para firmar cada solicitud de certificado.

$ openssl x509 -req -in mongodbserver1.csr -CA ca.pem -CAkey ca.key -set_serial 01 -days 3650 -out mongodbserver1.crt
$ openssl x509 -req -in mongodbserver1.csr -CA ca.pem -CAkey ca.key -set_serial 02 -days 3650 -out mongodbserver1.crt
$ openssl x509 -req -in mongodbserver3.csr -CA ca.pem -CAkey ca.key -set_serial 03 -days 3650 -out mongodbserver3.crt

4) Crear los archivos PEM (clave + certificado)

Se concatena la clave privada con el certificado para generar el archivo (.pem)

$ cat mongodbserver1.key mongodbserver1.crt > mongoserver1.pem
$ cat mongodbserver2.key mongodbserver2.crt > mongoserver2.pem
$ cat mongodbserver3.key mongodbserver3.crt > mongoserver3.pem

5) Crear certificado de cliente (para mTLS)

$ openssl req -nodes -newkey rsa:4096 -sha256 \

  -keyout mongodb_client.key \

  -out mongodb_client.csr \

  -subj «/C=ES/ST=Madrid/L=Madrid/O=Pruebas/OU=mongoPruebas/CN=mongoserver1,mongosrever2,mongoserver3»

La generación es muy similar al certificado del servidor, solo que en este caso indicamos el hostname de cada uno de los nodos del replica set.

6) Firmar el certificado con la CA y la clave

$ openssl x509 -req -in mongodb_client.csr -CA ca.pem -CAkey ca.key -set_serial 99 -days 3650 -out mongodb_client.crt

7) Concatenar el certificado y la clave para generar el pem

Se crea el archivo .pem para la autenticación.

$ cat mongodb_client.key mongodb_client.crt > mongodb_client.pem

8) Copiar los certificados a cada nodo

Una vez generados todos los archivos, se tienen que copiar a cada uno de los nodos que componen el replicaset y cambiar el usuario a “mongod”

$ scp ca.pem mongoserver1.pem mongod@mongoserver1:/mongo/mongocerts/

$ scp ca.pem mongoserver2.pem $ mongod@mongoserver2:/mongo/mongocerts/

$scp ca.pem mongoserver3.pem mongod@mongoserver3:/mongo/mongocerts/

$ sudo chown mongod:mongod /mongo/mongocerts

9) Configurar MongoDB para usar TLS

Editar el archivo de configuración (/etc/mongod.conf) de MongoDB en cada nodo del replicaset y modificarlo en función del archivo .pem

net:

  tls:

    mode: requireTLS

    certificateKeyFile: /mongo/mongocerts/mongoserver1.pem

    CAFile: /mongo/mongocerts/ca.pem

security:

  authorization: enabled

  clusterAuthMode: x509

replication:

  replSetName: rs-prueba

Reiniciar el servicio de MongoDB para que tomen efecto los cambios:

$ sudo systemctl restart mongod.service

Realizar prueba de conexión con mongosh. En este caso la conexión solo se podrá establecer si se tiene el certificado cliente y la ca.

$ mongosh \

  –tls \

  –tlsCAFile ca.pem \

  –tlsCertificateKeyFile mongodb_client.pem \

  –host «rs-prueba/mongoserver1:27017,mongoserver2:27017,mongoserver3:27017»

Conclusión

En este blog hemos visto los conceptos básicos sobre TLS/SSL, certificados X.509 y cómo usarlos para la configuración de MongoDB en un replica set.

Vemos que configurar TLS en MongoDB no es complicado, pero sí requiere orden y precisión.

Con esta guía puedes desplegar un replica set seguro, cifrado y preparado para entornos corporativos o de producción.

Para asegurar el entorno de su empresa en MongoDB o desplegar un replica set preparado para producción, en Hopla podemos acompañarle en el diseño, implementación y optimización de una infraestructura sólida, segura y adaptada a sus necesidades.

Contacte con nuestro equipo

Referencias:

Comparte en:

Categorías

Últimos artículos

Actualización EDB Postgres AI con mano robótica y cubo

Introducción EnterpriseDB (EDB) ha actualizado recientemente su plataforma y ecosistema de productos que operan en torno a PostgreSql , para [...]

Rostro robótico y título GridGain para IA en tiempo real

Índice Plataforma de datos en memoria unificada: funcionalidades clave Caso de uso: Predicción de glucosa en tiempo real (Healthcare) Introducción [...]

Migrar una plataforma de virtualización no es solo “mover máquinas virtuales”. Implica revisar arquitectura, operación, seguridad, continuidad de negocio y, [...]

Resumen de privacidad

Esta web utiliza cookies propias y de terceros. Algunas son estrictamente necesarias para que el sitio funcione correctamente y para recordar tus preferencias.

Utilizamos además cookies de analítica y experiencia de usuario (Google Analytics y Microsoft Clarity) que, solo si las aceptas, nos permiten elaborar estadísticas de uso y generar mapas de calor y grabaciones de sesiones de navegación de forma pseudonimizada, con el fin de mejorar la usabilidad de la web.

Puedes aceptar todas las cookies, rechazarlas o configurarlas por categorías en cualquier momento.