Docs Menu
Docs Home
/
Manual de base de datos
/

X.509

MongoDB es compatible con la autenticación de certificados X.509 para la autenticación de clientes y la autenticación interna de los nodos de sets de réplicas y clústeres particionados.

La autenticación del certificado X.509 requiere un certificado seguro Conexión TLS/SSL.

Para uso en producción, la implementación de MongoDB debe utilizar certificados válidos generados y firmados por una autoridad certificadora. El usuario o la organización pueden generar y mantener una autoridad de certificación independiente, o utilizar certificados generados por proveedores de TLS de terceros. La obtención y gestión de certificados está fuera del alcance de esta documentación.

Para autenticarse en los servidores, los clientes pueden usar certificados X.509 en lugar de nombres de usuario y contraseñas.

Requisitos del certificado de cliente:

  • Una única entidad de certificación (CA) debe emitir los certificados tanto para el cliente como para el servidor.

  • Cada usuario único de MongoDB debe tener un certificado único.

  • El certificado X.509 no debe caducar.

    Nota

  • Los certificados de cliente deben contener los siguientes campos:

    keyUsage = digitalSignature
    extendedKeyUsage = clientAuth
  • Al menos uno de los siguientes atributos del certificado de cliente debe ser diferente de los atributos tanto del net.tls.clusterFile como del net.tls.certificateKeyFile del servidor:

    • Organización (O)

    • Unidad Organizativa (OU)

    • Componente del dominio (DC)

  • El subject de un certificado de cliente X.509, que contiene el nombre distinguido (DN), debe ser diferente de los subject de los certificados de nodos X.509. Si la implementación de MongoDB tiene tlsX509ClusterAuthDNOverride configurado, el asunto del certificado X.509 del cliente no debe coincidir con ese valor.

    Importante

    Si el asunto de un certificado X.509 de cliente coincide con los atributos O, OU y DC del Certificado de nodo X.509 (o tlsX509ClusterAuthDNOverride, si se estableció) exactamente, se acepta la conexión del cliente, se conceden permisos completos y aparece un mensaje de advertencia en el registro.

    Solo los certificados x509 de nodos del clúster deben utilizar las mismas combinaciones de atributos O, OU y DC.

Para autenticar con un certificado de cliente, primero se debe añadir el subject del certificado de cliente como usuario de MongoDB en la base de datos $external. La base de datos $external es la base de datos de autenticación para el usuario.

Cada certificado de cliente X.509 único es para un usuario de MongoDB. No puedes utilizar un único certificado de cliente para autenticar a más de un usuario de MongoDB.

Para usar sesiones de cliente y garantías de coherencia causal con usuarios de autenticación $external (usuarios Kerberos, LDAP o X.509), los nombres de usuario no pueden superar los 10k bytes.

A partir de MongoDB 5.0, mongod y mongos ahora emiten una advertencia de inicio cuando sus certificados no incluyen un atributo Nombre Alternativo del Sujeto.

Las siguientes plataformas no admiten la validación de nombres comunes:

  • iOS 13 y superior

  • MacOS 10.15 y superior

  • Go 1.15 o superior

Los clientes que usan estas plataformas no se autenticarán en los servidores de MongoDB que usan certificados X.509 cuyos nombres de host están especificados por los atributos CommonName.

Para la autenticación interna entre nodos de clústeres particionados y sets de réplicas, puedes usar certificados X.509 en lugar de archivos de claves.

Utilice certificados de miembro para verificar la pertenencia a un clúster fragmentado o a un conjunto de réplicas. Los certificados de miembro se almacenan en y. Requisitos de los certificados de net.tls.clusterFile net.tls.certificateKeyFilemiembro:

  • Una única autoridad de certificación (CA) debe emitir todos los certificados x.509 para los miembros de un clúster fragmentado o un conjunto de réplicas.

  • El certificado509 x. no debe estar vencido.

    Nota

    mongod / mongos genera un registro de advertencia en la conexión si el certificado X.509 presentado caduca dentro de 30 días a partir de la hora del sistema host mongod/mongos.

  • El nombre distinguidoDN (), que se encuentra en el del certificado de subject miembro, debe especificar un valor no vacío para al menos uno de los siguientes atributos:

    • la organización (O)

    • la Unidad Organizativa (OU)

    • El componente del dominio (DC)

  • En implementaciones multiclúster, cada clúster debe usar un509 certificado miembro X. diferente. Cada certificado debe tener valores únicos en los campos de nombre distintivo O OU DC (DN), y.

    Si dos clústeres tienen certificados con los mismos valores DN, un servidor comprometido en un clúster puede autenticarse como miembro del otro.

  • Cada certificado de nodo de clúster debe tener Os, OUs y DCs idénticos en sus certificados net.tls.clusterFile y net.tls.certificateKeyFile. Esto también se aplica al valor tlsX509ClusterAuthDNOverride, si está configurado. El orden de los atributos no importa.

    A continuación, se muestra un ejemplo. Los dos DNa continuación tienen especificaciones coincidentes para O y OU, y DC no está especificado.

    CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
    C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

    El siguiente ejemplo es incorrecto porque los DNs no coinciden. Un DN tiene dos especificaciones de OU y el otro tiene solo una especificación de OU.

    CN=host1,OU=Dept1,OU=Sales,O=MongoDB
    CN=host2,OU=Dept1,O=MongoDB
  • El nombre común (CN) o una de las entradas del nombre alternativo del sujeto (SAN) deben coincidir con el nombre de host del servidor de los demás miembros del clúster. A partir de MongoDB 4.2, al comparar SAN, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo comparaba nombres DNS.

    Por ejemplo, los certificados de un clúster podrían tener los siguientes subject:

    subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
    subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
    subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US
  • Si el certificado utilizado como certificateKeyFile incluye extendedKeyUsage, el valor debe incluir clientAuth ("Autenticación de cliente web TLS") y serverAuth ("Autenticación de servidor web TLS").

    extendedKeyUsage = clientAuth, serverAuth
  • Si el certificado utilizado como clusterFile incluye extendedKeyUsage, el valor debe incluir clientAuth.

    extendedKeyUsage = clientAuth

Se puede usar TLS para la autenticación interna entre cada miembro del set de réplicas (cada instancia mongod) o de un clúster particionado (cada instancia mongod y mongos).

Para utilizar TLS para la autenticación interna, utiliza la siguiente configuración:

Importante

Si configuras --tlsMode a cualquier valor distinto de disabled, MongoDB usa el certificado especificado en net.tls.certificateKeyFile para la autenticación tanto del servidor como del cliente en las conexiones internas del set de réplicas. Esta configuración del certificado se aplica independientemente de si estableces security.clusterAuthMode en X.509.

Las instancias mongod y mongos utilizan sus archivos de claves de certificado para demostrar su identidad a los clientes, pero los archivos de claves de certificado también pueden usarse para la autenticación de nodos. Si no especificas un archivo de clúster, los nodos usan sus archivos de claves de certificado para la autenticación de membresía. Especifica el archivo de clave del certificado con net.tls.certificateKeyFile o --tlsCertificateKeyFile.

Para utilizar el archivo de claves de certificado tanto para la autenticación de clientes como para la autenticación de miembros, el certificado debe:

  • Omite extendedKeyUsage o

  • Especifica extendedKeyUsage = serverAuth, clientAuth

Volver

Autenticar Clientes

En esta página