X.509

Requisitos del certificado de cliente

Los certificados de cliente deben tener las siguientes propiedades:

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

• Los certificados de cliente deben contener los siguientes campos:

  keyUsage = digitalSignature
  extendedKeyUsage = clientAuth

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

• El sujeto de un certificado x.509 del cliente, que contiene el Nombre Distinguido (DN), debe diferir de los sujetos de los certificados x.509 de nodo.

  Importante

  Si el sujeto de un certificado x.509 del cliente coincide exactamente con los atributos O, OU y DC del Certificado x.509 de nodo (o tlsX509ClusterAuthDNOverride, si está configurado), se acepta la conexión del cliente, se otorgan todos los permisos 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.

  Si la implementación de MongoDB tiene tlsX509ClusterAuthDNOverride configurada, el sujeto del certificado x.509 del cliente no debe coincidir con ese valor.

  Si la implementación de MongoDB tiene tlsX509ClusterAuthDNOverride configurado, el sujeto del certificado x.509 del cliente también debe diferir de ese valor.

• El certificado x.509 no debe estar caducado.

  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.

Usuario de MongoDB y base de datos $external

Para autenticarte con un certificado de cliente, primero debes añadir el valor del subject del certificado de cliente como usuario de MongoDB. Cada certificado de cliente único x.509 corresponde a un único usuario de MongoDB. No puedes utilizar un único certificado de cliente para autenticar a más de un usuario de MongoDB.

Agregue al usuario en la base de datos $external. La base de datos $external es la base de datos de autenticación del usuario.

Para usar Sesiones de Cliente y Garantías de coherencia causal con usuarios de autenticación de $external (usuarios Kerberos, LDAP o x.509), los nombres de usuario no pueden superar los 10 000 bytes.

Advertencia de inicio de conexión TLS con certificado X509

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 utilizan estas plataformas no autenticarán en servidores MongoDB que utilizan un certificado X.509 cuyos nombres de host están especificados por atributos CommonName.

Requisitos del certificado de nodo

Los certificados de miembro que usas para verificar la membresía en un clúster fragmentado o en un set de réplicas (net.tls.clusterFile, si se especifica, y net.tls.certificateKeyFile), deben tener las siguientes propiedades:

• Una única Autoridad Certificadora (CA) debe emitir todos los certificados x.509 para los nodos de un clúster o un set de réplicas.

• El Nombre Distinguido (DN), que se encuentra en el subject del certificado de nodo, 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)

• Los atributos de la organización (O), los atributos de la unidad organizativa (OU) y los componentes del dominio (DC) deben coincidir con los de ambos certificados net.tls.clusterFile y net.tls.certificateKeyFile para los demás miembros del clúster (o el valor de tlsX509ClusterAuthDNOverride, si está configurado).

  Para coincidir, el certificado debe coincidir con todas las especificaciones de estos atributos, incluso la no especificación de estos atributos. El orden de los atributos no importa.

  En el siguiente ejemplo, los dos DN contienen especificaciones coincidentes para O, OU, así como la no especificación del atributo DC.

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

  Sin embargo, los dos siguientes DN contienen una diferencia en el atributo OU porque uno de ellos contiene dos especificaciones OU y el otro solo una especificación.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

• En implementaciones multi-cluster, cada clúster debe usar un certificado de nodo X.509 diferente. Cada certificado debe tener valores únicos en los campos del Nombre Distinguido (ND) O, OU y DC.

  Si dos clústeres tienen certificados con los mismos valores de nombre distinguido, un servidor comprometido en un clúster puede autenticarse como nodo del otro.

• El Nombre Común (CN) o una de las entradas de Nombre Alternativo del Sujeto (SAN) deben coincidir con el nombre del servidor para los demás nodos del clúster. A partir de MongoDB 4.2, al comparar SANs, MongoDB puede comparar nombres DNS o direcciones IP. En versiones anteriores, MongoDB solo compara nombres DNS.

  Por ejemplo, los certificados para un clúster podrían tener los siguientes sujetos:

  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 el certificateKeyFile incluye extendedKeyUsage, el valor debe incluir tanto clientAuth (“Autenticación de cliente web TLS”) como 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

• El certificado x.509 no debe estar caducado.

  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.

Configuración de MongoDB para la autenticación de nodos

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:

• security.clusterAuthMode o --clusterAuthMode configurado para x509

• net.tls.clusterFile or --tlsClusterFile

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

Para utilizar el certificate key file tanto para la autenticación del cliente como la autenticación de membresía, el certificado debe:

• Omite extendedKeyUsage o

• Especifica extendedKeyUsage = serverAuth, clientAuth