/ /

/ /

Rotar certificados en clústeres autogestionados sin clusterAuthX509

Los nodos de un set de réplicas o de un clúster pueden usar 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 no utiliza el net.tls.clusterAuthX509 configuración para ajustar los atributos del Nombre Distinguido (DN).

Nota

Para realizar una actualización continua para rotar certificados en un clúster que use la configuración net.tls.clusterAuthX509 o en un clúster que use esta configuración después de la actualización, consulta Rotar certificados en clústeres autogestionados con clusterAuthX509.

Cuando un nodo servidor recibe una solicitud de conexión, compara los atributos nombre distinguido (DN) en el campo subject de los certificados presentados con los atributos DN de sujeto de sus propios certificados. Los certificados coinciden si sus sujetos contienen los mismos valores para los atributos de Organización (O), Unidad Organizativa (OU) y Componente de Dominio (DC). Un archivo de configuración de un servidor también puede especificar atributos de nombre distinguido alternativos para utilizar en la coincidencia del parámetro tlsX509ClusterAuthDNOverride. Si los atributos de nombre distinguido del sujeto del servidor o el valor configurado tlsX509ClusterAuthDNOverride coinciden con los atributos de nombre distinguido del sujeto del certificado presentado, el servidor trata la conexión como 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.

Para cada miembro secundario, conecta mongosh al nodo, entonces:

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.

Gira X.509 con nuevos atributos clusterAuthX509