Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

Rote X.509 certificados para utilizar valores de extensión en clústeres autogestionados

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 migrar del uso de los atributos de Nombre Distinguido (DN) del certificado al uso de valores de extensión para identificar a los nodos de un clúster.

Cuando un servidor está configurado con el net.tls.clusterAuthX509.extensionValueLa configuración recibe una solicitud de conexión y compara la cadena de valores de extensión de los certificados presentados con los valores configurados en la configuración extensionValue y tlsClusterAuthX509Override el parámetro. Si los valores coinciden, trata la conexión como miembro del clúster.

Los clústeres que adopten nuevos certificados pueden utilizar el parámetro tlsClusterAuthX509Override para aceptar certificados X.509 con diferentes atributos de nombre distinguido 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.

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 MongoDB y la unidad organizativa MongoDB Server. Estos atributos de nombre distinguido se configuran usando la opción net.tls.clusterAuthX509.attributes.

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=MongoDB, OU=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.

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 attributes.

Inicialmente, los clústeres identifican a los nodos utilizando valores DN. Con los nuevos certificados, los servidores identifican a los nodos utilizando el valor de extensión mongodb://example.mongodb.net y ignoran los atributos de los certificados.

1

Actualice el archivo de configuración de cada servidor:

  • Cambia la configuración de clusterAuthX509 para que coincida con el nuevo certificado, reemplazando la configuración de attributes con la configuración de extensionValue.

  • 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:
extensionValue: mongodb://example.mongodb.net
security:
clusterAuthMode: x509
setParameter:
tlsClusterAuthX509Override: "{ attributes: 'O=MongoDB, OU=MongoDB Server' }"
2

Reinicie cada nodo del clúster secundario:

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

  3. Use el método rs.status() para determinar el estado nodo:

    rs.status().members
  4. 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 aceptan conexiones de pares de miembros que usan certificados con los nuevos valores de extensión, así como los antiguos atributos DN.

3

Reiniciar el miembro principal:

  1. 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.

  2. Utilice el método db.shutdownServer() para apagar el servidor:

    use admin
    db.shutdownServer()
  3. 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 el nuevo valor de extensión, así como los antiguos atributos DN.

4

Actualice el archivo de configuración de cada servidor:

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:
extensionValue: mongodb://example.mongodb.net
security:
clusterAuthMode: x509
setParameter:
tlsClusterAuthX509Override: "{ attributes: 'O=MongoDB, OU=MongoDB Server' }"
5

Reinicie cada nodo del clúster secundario:

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

  3. Use el método rs.status() para determinar el estado nodo:

    rs.status().members
  4. 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.

6

Reiniciar el miembro principal:

  1. 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.

  2. Utilice el método db.shutdownServer() para apagar el servidor:

    use admin
    db.shutdownServer()
  3. 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.

7

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:
extensionValue: mongodb://example.mongodb.net
security:
clusterAuthMode: x509

Esto garantiza que el servidor no configure los valores del certificado antiguo al iniciarse.

8

Reinicie cada nodo del clúster secundario:

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

  3. Use el método rs.status() para determinar el estado nodo:

    rs.status().members
  4. 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.

9

Reiniciar el miembro principal:

  1. 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.

  2. Utilice el método db.shutdownServer() para apagar el servidor:

    use admin
    db.shutdownServer()
  3. Reiniciar el servidor.

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

Volver

Gira X.509 con nuevos atributos clusterAuthX509

En esta página