Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
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 La configuración de net.tls.clusterAuthX509.extensionValue recibe una solicitud de conexión, compara la string de valor de la extensión de los certificados presentados con los valores configurados de la configuración extensionValue y el parámetro tlsClusterAuthX509Override. Si los valores coinciden, trata la conexión como un nodo 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 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.

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

Actualiza 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. Reinicie 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 entre pares de nodos que utilizan certificados con los nuevos valores de extensión, así como los antiguos atributos de nombre distinguido.

3

Reinicie 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. Reinicie el servidor.

El servidor primario en el set de réplicas se detiene y reinicia como un secundario que ahora acepta conexiones de pares de los nodos que utilizan certificados con el nuevo valor de extensión, así como los atributos de nombre distinguido anteriores.

4

Actualiza 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. Utiliza mongosh para conectarte a cada nodo secundario del clúster y luego utiliza el método db.shutdownServer() para detener el servidor:

    use admin
    db.shutdownServer()
  2. Reinicie 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 ahora usan los nuevos certificados X.509.

6

Reinicie 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. Reinicie el servidor.

El servidor primario en el set de réplicas se retira y se reinicia como un secundario que utiliza el nuevo certificado X.509.

7

Con todos los nodos del clúster usando ahora el nuevo certificado X.509, actualiza el archivo de configuración para remover las configuraciones setParameter para el parámetro tlsClusterAuthX509Override.

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 ajustes del certificado antiguo al inicio.

8

Reinicie cada nodo del clúster secundario:

  1. Utiliza mongosh para conectarte a cada nodo secundario del clúster y luego utiliza el método db.shutdownServer() para detener el servidor:

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

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