/ /

/ /

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 membresía para identificar otros servidores en la misma implementación. Este tutorial describe cómo realizar una actualización continua para rotar509 los certificados X. en un clúster que utiliza net.tls.clusterAuthX509.attributes configuraciones para configurar los atributos de nombre distinguido (DN) de los miembros 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 miembro del conjunto de réplicas a nuevos certificados que tienen atributos DN que utilizan la organización MongoDB y la unidad organizativa MongoDB Server.

Nota

El siguiente procedimiento presupone que los nuevos509 certificados X. cumplen con los requisitos de certificado de membresía y demás requisitos, y que la configuración del clúster identifica los certificados de pares mediante valores de nombre distinguido (DN). Para obtener más información, consulte Requisitos de certificados de miembro.

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

Actualice 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()
```
Reiniciar 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

Reiniciar 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()
```
Reiniciar 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

Actualice 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:

Utilice para conectarse mongosh db.shutdownServer() a cada miembro del clúster secundario, luego use el método para detener el servidor:
```
use admin
db.shutdownServer()
```
Reiniciar 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 conjunto de réplicas ahora utilizan los nuevos certificados X.509.

Reiniciar nodo principal del clúster

Reiniciar 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()
```
Reiniciar el servidor.

El servidor principal del conjunto de réplicas deja de funcionar y se reinicia como un servidor secundario que utiliza el nuevo certificado X.509.

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

Ahora que todos los miembros del clúster utilizan el nuevo certificado X.509, actualice el archivo de configuración para eliminar las configuraciones setParameter tlsClusterAuthX509Override para el parámetro.

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 valores del certificado antiguo al iniciarse.

Reiniciar los miembros del clúster secundarios

Reinicie cada nodo del clúster secundario:

Utilice para conectarse mongosh db.shutdownServer() a cada miembro del clúster secundario, luego use el método para detener el servidor:
```
use admin
db.shutdownServer()
```
Reiniciar 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

Reiniciar 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()
```
Reiniciar 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