/ /

Interno

Docs Home

/ /

Autenticación

Interno

Docs Home

Manual de base de datos

Implementaciones autogestionadas

Seguridad

Autenticación

Interno

Actualización gradual de los certificados X.509 que contienen nombre distinguido nuevo en clústeres autogestionados

Esta versión de la documentación se archivó y ya no se admite. Para actualizar tu implementación de 6.0, consulta el Procedimientos de actualización de MongoDB 7.0 .

Los nodos de un set de réplicas o de un clúster pueden usar Certificados X.509 para autenticación de membresías para identificar otros servidores en el mismo entorno de implementación.

Cuando un nodo de servidor recibe una solicitud de conexión, compara los atributos del Nombre Distinguido (DN) en el subject campo de los certificados presentados a los atributos de nombre distinguido del sujeto de sus propios certificados. Los certificados coinciden si sus temas contienen los mismos valores para los atributos Organización (O), Unidad Organizativa (OU) y Componente de Dominio (DC). El archivo de configuración de un servidor también puede especificar atributos de nombre distinguido alternativos para usar en la coincidencia en el parámetro tlsX509ClusterAuthDNOverride. Si los atributos de nombre distinguido del sujeto del nodo del servidor o el valor tlsX509ClusterAuthDNOverride configurado coinciden con los atributos de nombre distinguido del certificado presentado, el nodo del servidor trata la conexión como un nodo del clúster.

En algunas situaciones, puede que necesites actualizar los certificados de los nodos por otros nuevos con nuevos atributos de Nombre Distinguido (DN) del sujeto, como si una organización cambia 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 adoptan nuevos certificados pueden usar el parámetro tlsX509ClusterAuthDNOverride para aceptar certificados x.509 con diferentes atributos de nombre distinguido de sujeto durante el procedimiento de rotación de certificados. Una vez que todos los miembros utilizan certificados con el nuevo valor, remueve la anulación para comenzar a rechazar los certificados ahora obsoletos.

Acerca de esta tarea

Considera un conjunto de réplicas donde los certificados X.509 de cada nodo, configurados mediante las configuraciones clusterFile y certificateKeyFile, tienen atributos DN de sujeto de "OU=10gen Server,O=10gen".

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

net.tls.mode: requireTLS
net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem"
net.tls.CAFile: "./mycerts/ca.pem"
security.clusterAuthMode: x509
net.tls.clusterFile:  "./mycerts/10gen-cluster1.pem"
net.tls.clusterCAFile: "./mycerts/ca.pem"

El siguiente procedimiento actualiza los certificados de cada nodo a nuevos certificados que tienen atributos nombre distinguido del sujeto de "OU=MongoDB Server, O=MongoDB".

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

Establece el parámetro de anulación en todos los miembros.

Durante una actualización continua, los nodos se reinician uno a la vez con una nueva configuración. Para permitir que los nodos del servidor con los antiguos atributos de nombre distinguido del sujeto identifiquen a los nodos con los nuevos atributos de nombre distinguido del sujeto como miembros del clúster, establece el parámetro de reemplazo en los nuevos atributos de nombre distinguido del sujeto en todos los nodos en ejecución.

Para ello, modifique el archivo de configuración de cada servidor para establecer el parámetro tlsX509ClusterAuthDNOverride para utilizar los atributos de nombre distinguido del sujeto del nuevo certificado:

net.tls.mode: requireTLS
net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem"
net.tls.CAFile: "./mycerts/ca.pem"
security.clusterAuthMode: x509
net.tls.clusterFile:  "./mycerts/10gen-cluster1.pem"
net.tls.clusterCAFile: "./mycerts/ca.pem"
setParameter:
   tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB"

Esta configuración no se tendrá en cuenta hasta que reinicie cada nodo.

Reinicia todos los miembros.

Para realizar un reinicio en secuencia de todos los miembros, reinicia cada secundario y luego el primario.

Por cada miembro secundario, conecta mongosh al nodo y, a continuación:

Utiliza el método db.shutdownServer() para apagar el nodo:
```
use admin
db.shutdownServer()
```
Reinicia el nodo.
Antes de reiniciar el siguiente secundario, asegúrese de que este nodo haya alcanzado el estado SECONDARY. Para determinar el estado miembro, ejecuta rs.status() y lee el valor del campo stateStr.
```
rs.status().members
```

Para el miembro principal, conecta mongosh al nodo y luego:

Usa rs.stepDown() para destituir al nodo:
```
rs.stepDown()
```
Utiliza el método db.shutdownServer() para apagar el nodo:
```
use admin
db.shutdownServer()
```
Reinicia el nodo.

Ahora, todos los servidores en el conjunto de réplicas pueden usar el parámetro de anulación para aceptar conexiones de pares de nodos que usan certificados con los nuevos atributos del DN de sujeto.

Modificar la configuración de todos los nodos.

Actualiza el archivo de configuración de cada servidor:

Cambia la configuración net.tls.certificateKeyFile al nuevo certificado.
Cambia la configuración net.tls.clusterFile al nuevo certificado.
Establece el parámetro tlsX509ClusterAuthDNOverride para usar los atributos de nombre distinguido del certificado antiguo.

Por ejemplo:

net.tls.mode: requireTLS
net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem"
net.tls.CAFile: "./mycerts/ca.pem"
security.clusterAuthMode: x509
net.tls.clusterFile:  "./mycerts/mongodb-cluster1.pem"
net.tls.clusterCAFile: "./mycerts/ca.pem"
setParameter:
   tlsX509ClusterAuthDNOverride: "OU=10Gen Server,O=10Gen"

Esta configuración no se tendrá en cuenta hasta que reinicie cada nodo.

Reinicia todos los miembros.

Para aplicar la configuración actualizada a cada nodo, se debe realizar un reinicio secuencial de los nodos del servidor repitiendo el procedimiento desde el paso 2.

Durante este proceso, los nodos que se han reiniciado con nuevos certificados utilizarán los antiguos atributos nombre distinguido almacenados en tlsX509ClusterAuthDNOverride para identificar los nodos que presentan certificados antiguos. Los nodos que aún tienen certificados antiguos utilizarán el nuevo DN almacenado en tlsX509ClusterAuthDNOverride para identificar los nodos que presenten nuevos certificados.

Remover el parámetro de anulación de todos los nodos.

Para evitar que los nodos actualizados del servidor traten a los clientes que presentan el certificado antiguo como pares, elimina el parámetro tlsX509ClusterAuthDNOverride de todos los archivos de configuración de nodos servidores.

Por ejemplo:

net.tls.mode: requireTLS
net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem"
net.tls.CAFile: "./mycerts/ca.pem"
security.clusterAuthMode: x509
net.tls.clusterFile:  "./mycerts/mongodb-cluster1.pem"
net.tls.clusterCAFile: "./mycerts/ca.pem"

Esta configuración no se tendrá en cuenta hasta que reinicie cada nodo.

Reinicia todos los miembros.

Para aplicar la configuración actualizada a cada nodo, se debe realizar un reinicio secuencial de los nodos del servidor repitiendo el procedimiento desde el paso 2.

Todos los servidores en el set de réplicas ahora solo aceptan conexiones entre pares de miembros que utilicen certificados con los nuevos atributos DN de sujeto.

Volver

Actualizar a X.509 desde Keyfile.

Excepción de Localhost