El siguiente procedimiento configura la autenticación del certificado X.509 para la autenticación del cliente en un servidor independiente. mongod instancia. Esto también se conoce como TLS mutuo o mTLS.
Para utilizar la509 autenticación X. para conjuntos de réplicas o clústeres fragmentados, consulte Verificar la membresía del clúster con X.509 en MongoDB autoadministrado.
Requisitos previos
Una descripción completa de los certificados TLS/SSL, PKI (Infraestructura de Clave Pública), en particular los certificados X.509, y la autoridad de certificación queda fuera del alcance de este documento. Este tutorial presupone conocimientos previos de TLS/SSL y acceso a certificados X.509 válidos.
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.
Para utilizar la autenticación X.509, se debe especificar --tlsCAFile o net.tls.CAFile a menos que utilice --tlsCertificateSelector o --net.tls.certificateSelector.
Certificado del cliente X.509
Debe tener certificados X.509 válidos. Los certificados X. de cliente509 deben cumplir los requisitos de certificado de cliente.
Si especifica --tlsAllowInvalidCertificates net.tls.allowInvalidCertificates: trueo, un certificado no válido solo es suficiente para establecer una conexión TLS, pero no es suficiente para la autenticación.
Procedimiento
Implemente con autenticación X.509
Puede configurar una instancia mongod para509 la autenticación X. desde la línea de comandos.
Para configurar una instancia independiente, ejecute el siguiente mongod comando:
mongod --tlsMode requireTLS \ --tlsCertificateKeyFile <path to TLS/SSL certificate and key PEM file> \ --tlsCAFile <path to root CA PEM file> --bind_ip <hostnames>
Incluya opciones adicionales según sea necesario para su configuración.
La configuración de X.509 requiere:
Opción | notas |
|---|---|
Especifique | |
Especifique el certificado X.509 de la instancia para presentar a los clientes. | |
Especifique el archivo de autoridad de certificación para verificar los certificados presentados a la instancia. |
Puede configurar un mongod para509 la autenticación X. en el archivo de configuración.
Para configurar una mongod instancia independiente, agregue las siguientes opciones de configuración a su archivo de configuración:
net: tls: mode: requireTLS certificateKeyFile: <path to TLS/SSL certificate and key PEM file> CAFile: <path to root CA PEM file>
Incluya opciones adicionales según sea necesario para su configuración.
La configuración de X.509 requiere:
Opción | notas |
|---|---|
Especifique | |
Especifique el certificado X.509 de la instancia para presentar a los clientes. | |
Especifique el archivo de autoridad de certificación para verificar los certificados presentados a la instancia. |
Para configurar la509 autenticación X. para conjuntos de réplicas o clústeres fragmentados, consulte Verificar la membresía del clúster con X.509 en MongoDB autoadministrado.
Agregar X.509 Certificado subject como Usuario
Para autenticarse con un certificado de cliente, primero debe agregar el valor subject del certificado de cliente como usuario de MongoDB a la base de datos $external. Cada certificado de cliente X.509 único corresponde a un único usuario de MongoDB. No se puede usar un solo certificado de cliente para autenticar a más de un usuario de MongoDB.
Nota
Requisitos de nombre de usuario
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.Los RDN en la cadena
subjectdeben ser compatibles con el 2253 Estándar RFC.
Puede recuperar el
RFC2253formateadosubjectdel certificado del cliente con el siguiente comando:openssl x509 -in <pathToClientPEM> -inform PEM -subject -nameopt RFC2253 El comando devuelve la cadena
subjecty el certificado:subject= CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry -----BEGIN CERTIFICATE----- # ... -----END CERTIFICATE----- Agregue el valor
RFC2253compatible consubjectcomo usuario. Omita los espacios según sea necesario.El siguiente ejemplo agrega un usuario y le otorga el rol en
readWritelatestbase de datos y eluserAdminAnyDatabaserol:db.getSiblingDB("$external").runCommand( { createUser: "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry", roles: [ { role: "readWrite", db: "test" }, { role: "userAdminAnyDatabase", db: "admin" } ], writeConcern: { w: "majority" , wtimeout: 5000 } } ) Consulte Administrar usuarios y roles en implementaciones autoadministradas para obtener detalles sobre cómo agregar un usuario con roles.
Autenticarse con un certificado X.509
Después de haber agregado el509 sujeto del certificado de cliente X. como usuario MongoDB correspondiente, puede autenticarse con el certificado de cliente:
Para autenticarse durante la conexión, ejecute el siguiente comando:
mongosh --tls --tlsCertificateKeyFile <path to client PEM file> \ --tlsCAFile <path to root CA PEM file> \ --authenticationDatabase '$external' \ --authenticationMechanism MONGODB-X509
Opción | notas |
|---|---|
Especifique el archivo X.509 del cliente. | |
Especifique el archivo de autoridad de certificación para verificar el certificado presentado por la | |
Especifique | |
Especifique |
Puede conectarse sin autenticación y utilizar el db.auth() método para autenticarse después de la conexión.
Por ejemplo, si se usa mongosh,
mongosh --tls --tlsCertificateKeyFile <path to client PEM file> \ --tlsCAFile <path to root CA PEM file> OpciónnotasEspecifique el archivo X.509 del cliente.
Para autenticarse, usa el método
db.auth()en la base de datos$external. En el campomechanism, especifica"MONGODB-X509".db.getSiblingDB("$external").auth( { mechanism: "MONGODB-X509" } )
Próximos pasos
Para utilizar la509 autenticación X. para conjuntos de réplicas o clústeres fragmentados, consulte Verificar la membresía del clúster con X.509 en MongoDB autoadministrado.