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.
Autoridad de Certificación
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.
Certificados de cliente X.509
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
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
mongod/ registra una advertencia en la conexión simongosel509 certificado X. presentado caduca dentro de los30días posteriores a la hora delmongod/mongossistema host.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.clusterFilecomo delnet.tls.certificateKeyFiledel servidor:Organización (
O)Unidad Organizativa (
OU)Componente del dominio (
DC)
Nota
También puedes desactivar el parámetro
enforceUserClusterSeparationdurante el inicio para desactivar automáticamente la verificación deO/OU/DC. Esto permite que los certificados de nodos se autentiquen como usuarios almacenados en la base de datos$external.El
subjectde un certificado de cliente X.509, que contiene el nombre distinguido (DN), debe ser diferente de lossubjectde los certificados de nodos X.509. Si la implementación de MongoDB tienetlsX509ClusterAuthDNOverrideconfigurado, 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,OUyDCdel Certificado de nodo X.509 (otlsX509ClusterAuthDNOverride, 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,OUyDC.
Usuario de MongoDB y base de datos $external
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.
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 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.
Certificados de nodo X.509
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.
Requisitos del certificado de nodo
Cuando TLS esté habilitado, utilice certificados de nodo para verificar la pertenencia a las conexiones internas de un clúster o un set de réplicas. Puede configurar las rutas de los archivos de certificados de nodo con las opciones net.tls.clusterFile y net.tls.certificateKeyFile. Los miembros tienen los siguientes requisitos de configuración:
La configuración del nodo del clúster debe especificar un valor no vacío para al menos uno de los atributos utilizados para la autenticación. Por defecto, MongoDB acepta:
la organización (
O)la Unidad Organizativa (
OU)El componente del dominio (
DC)
MongoDB verifica que las entradas coincidan exactamente en todos los certificados de nodo. Si enumeras varios valores de
OU, todos los certificados deben usar una lista idéntica.Se pueden especificar atributos alternativos para usar en la autenticación al configurar
net.tls.clusterAuthX509.extensionValue.La configuración de los nodos del clúster debe incluir el mismo
net.tls.clusterAuthX509.attributesy usar valores coincidentes. El orden de los atributos no importa. El siguiente ejemplo configuraOyOU, pero noDC:net: tls: clusterAuthX509: attributes: O=MongoDB, OU=MongoDB Server
Los certificados tienen los siguientes requisitos:
Una única Autoridad Certificadora (CA) debe emitir todos los certificados X.509 para los miembros de un clúster o de un set de réplicas.
Al menos una de las entradas del nombre alternativo del sujeto (
SAN) debe coincidir con el nombre de host del servidor usado por otros miembros del clúster. Al compararSAN, MongoDB puede comparar nombres DNS o direcciones IP.Si no especifica
subjectAltName, MongoDB compara el nombre común (CN). Sin embargo, este uso del CN está obsoleto. RFC2818
El uso de clave y el uso extendido de clave son extensiones X.509 que definen y restringen estrictamente el uso de la clave asociada a un certificado. Ambas extensiones son opcionales. Si tlsCertificateKeyFile o tlsClusterFile apuntan a certificados que omiten estas extensiones, no se aplican restricciones en el uso del certificado.
Si los certificados X.509 utilizados para tlsCertificateKeyFile o tlsClusterFile incluyen la extensión de Uso extendido de clave (EKU), estos deben cumplir con las siguientes reglas:
tlsCertificateKeyFiledeben incluirserverAuthen EKU.extendedKeyUsage = serverAuth tlsClusterFiledebes incluirclientAuthen EKU:extendedKeyUsage = clientAuth Si se omite
tlsClusterFiley solo se configuratlsCertificateKeyFile,tlsCertificateKeyFiledeben incluir tantoserverAuthcomoclientAuthen EKU:extendedKeyUsage = clientAuth, serverAuth
Si los certificados X.509 utilizados para tlsCertificateKeyFile o tlsClusterFile incluyen la extensión de Uso de clave (KU), esta se debe configurar de la siguiente manera:
tlsCertificateKeyFiledebe contenerdigitalSignature,keyEnciphermentykeyAgreementen su extensión KU:keyUsage = digitalSignature, keyEncipherment, keyAgreement tlsClusterFiledebe contenerdigitalSignatureen su extensión KU:keyUsage = digitalSignature
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.clusterAuthModeo--clusterAuthModeconfigurado parax509
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
extendedKeyUsageoEspecifica
extendedKeyUsage = serverAuth, clientAuth