/ /

/ /

Rotar certificados en clústeres autoadministrados 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 certificados en un clúster que no usa la net.tls.clusterAuthX509 configuración y no lo hará después de la actualización, consulte Rotar certificados en clústeres autoadministrados sin clusterAuthX.509

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

En algunas situaciones, es posible que necesite actualizar los certificados de miembro a nuevos certificados con un nuevo nombre distintivo (DN), por ejemplo, si una organización cambia de nombre. En una actualización continua, los certificados de miembro se actualizan uno a uno y la implementación no genera tiempo de inactividad.

Los clústeres que adopten nuevos certificados pueden usar el parámetro para tlsClusterAuthX509Override aceptar509 certificados X. con diferentes atributos de DN de sujeto durante el proceso de rotación de certificados. Una vez que todos los miembros usen certificados con el nuevo valor, elimine la anulación para comenzar a rechazar los certificados 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 miembro para usar nuevos509 certificados X. en un clúster configurado con la net.tls.clusterAuthX509.attributes configuración.

Los nuevos certificados tienen nombres distinguidos (DN) que cambian los atributos de organización (O) de 10gen a MongoDB y el atributo de unidad organizativa (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:

Cambie la configuración para utilizar los valores del nuevo attributes certificado
Establezca el parámetro para utilizar los atributos DN del certificado tlsClusterAuthX509Override 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 miembros del clúster secundario

Reinicie cada miembro del clúster secundario:

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

Los servidores secundarios en el conjunto de réplicas ahora aceptan conexiones de pares de miembros que usan certificados con los nuevos atributos DN.

Reiniciar miembro del clúster principal

Reiniciar el miembro principal:

Conéctese al principal usando,mongosh rs.stepDown() luego use el método para reducir el miembro a principal:
```
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 en el conjunto de réplicas deja de funcionar y se reinicia como un servidor secundario que ahora acepta conexiones de pares de miembros que usan certificados con los nuevos atributos DN.

Actualizar los certificados TLS

Actualice el archivo de configuración de cada servidor:

Cambie la configuración para utilizar el nuevo net.tls.certificateKeyFile certificado.
Cambie la configuración para utilizar el nuevo net.tls.clusterFile 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 miembros del clúster secundario

Reinicie cada miembro 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.
Utilice el método para determinar el estado rs.status() miembro:
```
rs.status().members
```
Espere a que stateStr el campo de este miembro muestre un valor de SECONDARY y luego reinicie el siguiente secundario.

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

Reiniciar miembro del clúster principal

Reiniciar el miembro principal:

Conéctese al principal usando,mongosh rs.stepDown() luego use el método para reducir el miembro a principal:
```
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 en el conjunto de réplicas deja de funcionar y se reinicia como un servidor secundario que utiliza el nuevo certificado X.509.

Eliminar la configuración de anulación de la certificación DN

Ahora que todos los miembros del clúster utilizan el nuevo509 certificado X., actualice el archivo tlsClusterAuthX509Override de configuración para eliminar las configuraciones setParameter 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 miembros del clúster secundario

Reinicie cada miembro 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.
Utilice el método para determinar el estado rs.status() miembro:
```
rs.status().members
```
Espere a que stateStr el campo de este miembro muestre un valor de SECONDARY y luego reinicie el siguiente secundario.

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

Reiniciar miembro del clúster principal

Reiniciar el miembro principal:

Conéctese al principal usando,mongosh rs.stepDown() luego use el método para reducir el miembro a principal:
```
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 se desactiva y se reinicia como un servidor 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