/ /

/ /

Rotar certificados en clústeres autogestionados con clusterAuthX509

Nuevo en la versión 7.0.

Los miembros del clúster pueden utilizar Certificados X.509 para la autenticación de miembros para identificar otros servidores en la misma implementación. Este tutorial describe cómo realizar una actualización progresiva para rotar los certificados X.509 en un clúster que utiliza el net.tls.clusterAuthX509.attributes configuraciones para configurar los atributos del Nombre Distinguido (DN) de los nodos del clúster.

Nota

Para realizar una actualización continua para rotar los certificados en un clúster que no utiliza la configuración de net.tls.clusterAuthX509 y no lo hará después de la actualización, vea Rotar certificados en clústeres autogestionados sin clusterAuthX509.

Cuando un servidor configurado con la configuración net.tls.clusterAuthX509.attributes recibe una solicitud de conexión, compara los atributos del Nombre Distinguido (DN) en el campo subject de los certificados presentados con los valores configurados de la configuración attributes y el parámetro tlsClusterAuthX509Override. Si los valores coinciden, trata la conexión como un nodo del clúster.

En algunas situaciones, es posible que debas actualizar los certificados de nodos a nuevos certificados con un nuevo Nombre Distinguido (DN), como si una organización cambiara su nombre. En una actualización continuamente, los certificados de nodo se actualizan uno a la vez, y la implementación no incurre en ningún tiempo de inactividad.

Los clústeres que adopten nuevos certificados pueden usar el parámetro tlsClusterAuthX509Override para aceptar certificados X.509 con diferentes atributos de nombre distinguido de sujeto durante el procedimiento de rotación de certificados. Cuando todos los nodos vayan a usar certificados con el nuevo valor, remuevan la anulación para comenzar a rechazar los certificados, ahora obsoletos.

Acerca de esta tarea

Considera un set de réplicas donde los certificados de los nodos, configurados mediante la opción clusterFile y la opción certificateKeyFile, tienen atributos de nombre distinguido que utilizan la organización 10gen y la unidad organizativa 10gen Server. Estos atributos de nombre distinguido se configuran usando la opción net.tls.clusterAuthX509.attributes.

Un nodo de este set de réplicas tiene el siguiente archivo de configuración:

security:
  clusterAuthMode:      x509
net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/10gen-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/10gen-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=10gen, OU=10gen Server

El siguiente procedimiento actualiza los certificados X.509 de cada set de réplicas por nuevos certificados que tienen atributos DN que usan la MongoDB organización y la MongoDB Server unidad organizacional.

Nota

El siguiente procedimiento asume que los nuevos certificados X.509 cumplen con los requisitos de certificados de asociación y todos los demás requisitos, y que la configuración del clúster identifica los certificaciones de peer usando valores de Nombre Distinguido (DN). Para obtener más información, consulte Requisitos del Certificado de Nodos.

Pasos

Estos pasos actualizan los certificados de los nodos para que utilicen los nuevos certificados X.509 en un clúster configurado con la configuración net.tls.clusterAuthX509.attributes.

Los nuevos certificados tienen Nombres Distinguidos (DN) que cambian los atributos de Organización (O) de 10gen a MongoDB y el atributo de Unidad Organizacional (OU) de 10gen Server a MongoDB Server.

Actualizar la configuración de membresía del clúster TLS

Actualiza el archivo de configuración de cada servidor:

Cambio attributes de configuración para utilizar los valores del nuevo certificado
Establece el parámetro tlsClusterAuthX509Override para usar los atributos de nombre distinguido del certificado antiguo.

Por ejemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }

Reiniciar los miembros del clúster secundarios

Reinicie cada nodo del clúster secundario:

Usar mongosh para conectarse a cada nodo secundario del clúster y luego use el método db.shutdownServer() para detener el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.
Use el método rs.status() para determinar el estado nodo:
```
rs.status().members
```
Espere a que el campo stateStr para este nodo muestre un valor de SECONDARY, luego reinicie el siguiente secundario.

Los servidores secundarios del set de réplicas ahora aceptan conexiones de pares de miembros que utilizan certificados con los nuevos atributos DN.

Reiniciar nodo principal del clúster

Reinicie el miembro principal:

Conéctate al primario utilizando mongosh, luego utiliza el método rs.stepDown() para degradar al nodo como primario:
```
rs.stepDown()
```
El clúster promueve un secundario con el nuevo certificado para que sirva como nuevo primario.
Utilice el método db.shutdownServer() para apagar el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.

El servidor primario en el set de réplicas renuncia y se reinicia como secundario, aceptando ahora conexiones de pares de nodos que utilizan certificados con los nuevos atributos de nombre distinguido (DN).

Actualizar los certificados TLS

Actualiza el archivo de configuración de cada servidor:

Cambia la configuración net.tls.certificateKeyFile para usar el nuevo certificado.
Cambia la configuración net.tls.clusterFile para usar el nuevo certificado.

Por ejemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server2.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster2.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }

Reiniciar los miembros del clúster secundarios

Reinicie cada nodo del clúster secundario:

Utiliza mongosh para conectarte a cada nodo secundario del clúster y luego utiliza el método db.shutdownServer() para detener el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.
Use el método rs.status() para determinar el estado nodo:
```
rs.status().members
```
Espere a que el campo stateStr para este nodo muestre un valor de SECONDARY, luego reinicie el siguiente secundario.

Los servidores secundarios en el set de réplicas ahora usan los nuevos certificados X.509.

Reiniciar nodo principal del clúster

Reinicie el miembro principal:

Conéctate al primario utilizando mongosh, luego utiliza el método rs.stepDown() para degradar al nodo como primario:
```
rs.stepDown()
```
El clúster promueve un secundario con el nuevo certificado para que sirva como nuevo primario.
Utilice el método db.shutdownServer() para apagar el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.

El servidor primario en el set de réplicas se retira y se reinicia como un secundario que utiliza el nuevo certificado X.509.

Remover la configuración de anulación de certificación de nombre distinguido

Con todos los nodos del clúster usando ahora el nuevo certificado X.509, actualiza el archivo de configuración para remover las configuraciones setParameter para el parámetro tlsClusterAuthX509Override.

Por ejemplo:

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509

Esto garantiza que el servidor no configure los ajustes del certificado antiguo al inicio.

Reiniciar los miembros del clúster secundarios

Reinicie cada nodo del clúster secundario:

Utiliza mongosh para conectarte a cada nodo secundario del clúster y luego utiliza el método db.shutdownServer() para detener el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.
Use el método rs.status() para determinar el estado nodo:
```
rs.status().members
```
Espere a que el campo stateStr para este nodo muestre un valor de SECONDARY, luego reinicie el siguiente secundario.

Los servidores secundarios en el set de réplicas se reinician y ya no aceptan conexiones de los certificados X.509 antiguos.

Reiniciar nodo principal del clúster

Reinicie el miembro principal:

Conéctate al primario utilizando mongosh, luego utiliza el método rs.stepDown() para degradar al nodo como primario:
```
rs.stepDown()
```
El clúster promueve un secundario con el nuevo certificado para que sirva como nuevo primario.
Utilice el método db.shutdownServer() para apagar el servidor:
```
use admin
db.shutdownServer()
```
Reinicie el servidor.

El servidor primario se retira y se reinicia como secundario que ya no acepta conexiones de los antiguos certificados X.509.

Obtén más información

Volver

Girar X.509 con nuevo nombre distinguido

Gira X.509 para utilizar valores de extensión