Se usó la API de Cloud Translation para traducir esta página.

Descripción general de la TLS mutua

La TLS mutua, o mTLS, es un protocolo estándar de la industria para la autenticación mutua entre un cliente y un servidor. Garantiza que el cliente y el servidor se autentiquen mutuamente, ya que verifica que cada uno tenga un certificado válido emitido por una autoridad certificadora (AC) de confianza. A diferencia de la TLS estándar, en la que solo se autentica el servidor, la mTLS requiere que el cliente y el servidor presenten certificados que confirmen las identidades de ambas partes antes de que se establezca la comunicación.

La mTLS se configura en el recurso de proxy HTTPS de destino de todos los balanceadores de cargas de aplicaciones:

Balanceador de cargas de aplicaciones externo global
Balanceador de cargas de aplicaciones clásico
Balanceador de cargas de aplicaciones externo regional
Balanceador de cargas de aplicaciones interno regional
Balanceador de cargas de aplicaciones interno entre regiones

La mTLS usa la infraestructura de clave pública (PKI) para autenticar la identidad de las entidades que se comunican a través de la red. La infraestructura incluye tres componentes: un cliente, un servidor y una autoridad certificadora (AC). La mTLS para los balanceadores de cargas admite las siguientes funciones:

Verifica que el cliente que presenta el certificado posea su clave privada.
Valida los certificados de cliente en cualquiera de estos dos modos:
- Rechaza certificados no válidos: Aplica una autenticación estricta rechazando las solicitudes si no se puede validar la cadena de certificados de cliente.
- Permitir certificados no válidos o faltantes: Proporciona flexibilidad, ya que pasa todas las solicitudes al backend, incluso si falta un certificado de cliente o no es válido.
Valida los certificados de cliente con un ancla de PKI subida (certificado raíz), con la opción de agregar varias anclas por separado para permitir una migración sin problemas de una PKI antigua a una nueva sin tiempo de inactividad.
Proporciona certificados intermedios adicionales para ayudar a construir la ruta de validación del certificado del cliente en las anclas de la PKI especificadas (certificados raíz). Estos certificados intermedios permiten que mTLS funcione con clientes que no proporcionan la cadena de certificados completa.
Genera y pasa una huella digital del certificado al backend como un encabezado de solicitud personalizado.
Pasa los campos seleccionados extraídos del certificado al backend mediante encabezados personalizados.
Pasa el resultado de la validación y cualquier error de validación al backend mediante encabezados personalizados.

Requisitos del certificado

Cuando configures certificados para mTLS, asegúrate de que cumplan con los siguientes requisitos:

Las herramientas de criptografía modernas forman la base de la autenticación de mTLS. Los certificados deben usar algoritmos RSA o ECDSA para el intercambio de claves. Los algoritmos de hash deben usar SHA-256 o una función hash criptográfica más segura. No se admiten algoritmos de hash como MD4, MD5 y SHA-1.
Para certificados (de hoja) de cliente:
- La extensión Restricciones básicas no debe contener CA=true.
- La extensión Uso extendido de la clave debe contener clientAuth.
- La extensión Uso extendido de la clave no debe contener los campos codeSigning, timeStamping o OCSPSigning.
- El certificado no debe estar vencido.
- El certificado del cliente no puede ser un certificado autofirmado.
Para certificados intermedios y raíz:
- La extensión Restricciones básicas debe contener CA=true.
- La extensión Uso de la clave se debe establecer en keyCertSign.
- La extensión Uso extendido de la clave debe contener el campo clientAuth.
- El certificado no debe estar vencido.

Arquitectura de una implementación de mTLS

Con mTLS, puedes configurar un recurso de configuración de confianza, que contiene un almacén de confianza. El almacén de confianza encapsula un ancla de confianza (certificado raíz) y, de forma opcional, uno o más certificados intermedios. Cuando el balanceador de cargas recibe un certificado de cliente, lo valida estableciendo una cadena de confianza desde el certificado de cliente hasta el ancla de confianza configurada.

A continuación, se incluye una breve descripción general de los diferentes recursos que debes configurar para configurar la mTLS para el balanceador de cargas:

Configuración de confianza. Contiene un solo recurso de almacén de confianza, que, a su vez, encapsula un ancla de confianza (certificado raíz) y, de forma opcional, uno o más certificados intermedios. La configuración de confianza se usa para establecer una cadena de confianza entre el certificado de cliente y el ancla de confianza. Para obtener más información, consulta Configuraciones de confianza.

De manera opcional, si necesitas usar un certificado autofirmado, vencido o no válido, o si no tienes acceso a los certificados raíz y intermedios, puedes agregar ese certificado a la configuración de confianza en el campo allowlistedCertificates. No necesitas un almacén de confianza para agregar un certificado a una lista de entidades permitidas.

Agregar un certificado a la lista de entidades permitidas significa que este siempre se considera válido, siempre y cuando se pueda analizar, se establezca la prueba de posesión de la clave privada y se cumplan las restricciones del campo SAN del certificado.
Almacén de confianza. Contiene los certificados de ancla de confianza y de la autoridad certificadora (AC) intermedia que se usan para establecer una cadena de confianza y validar el certificado de cliente. Una AC se usa para emitir certificados de confianza para el cliente. La AC se identifica mediante el ancla de confianza (certificado raíz) del balanceador de cargas o los certificados de AC intermedios.

Puedes subir los siguientes tipos de certificados raíz y intermedios al almacén de confianza:
- Los certificados emitidos por CA de terceros que elijas.
- Certificados emitidos por AC privadas en tu control, como se describe en Configura la TLS mutua con una AC privada.
- Certificados proporcionados por el usuario, como se describe en Configura la TLS mutua con certificados proporcionados por el usuario.
Autenticación de cliente (también conocida como ServerTLSPolicy). especifica el modo de validación del cliente y el recurso de configuración de confianza que se usará cuando se validen los certificados de cliente. Cuando el cliente presenta un certificado no válido o ningún certificado al balanceador de cargas, el modo de validación del cliente especifica cómo se maneja la conexión del cliente. Puedes especificar todos los parámetros relacionados con la autenticación de mTLS en las políticas de TLS del servidor. El recurso de autenticación de cliente (ServerTLSPolicy) se adjunta al recurso de proxy HTTPS de destino.

En los siguientes diagramas, se muestran los diferentes componentes de mTLS conectados al recurso de proxy HTTPS de destino de los balanceadores de cargas de aplicaciones globales y regionales.

global

En el siguiente diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo. Esta arquitectura también se aplica al balanceador de cargas de aplicaciones interno entre regiones, que es un balanceador de cargas de aplicaciones interno que usa componentes globales.

regional

En el siguiente diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones interno regional. Esta arquitectura también se aplica al balanceador de cargas de aplicaciones externo regional, que es un balanceador de cargas de aplicaciones externo que usa componentes regionales.

Modo de validación del cliente

Cuando el cliente presenta un certificado no válido o ningún certificado al balanceador de cargas, el atributo clientValidationMode en el recurso de autenticación de clientes (ServerTLSPolicy) especifica cómo el balanceador de cargas controla la conexión del cliente.

Los valores del modo de validación del cliente son los siguientes:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Permite la conexión desde el cliente, incluso si la validación del certificado de cliente falló o no se presentó ningún certificado de cliente. En este modo, el balanceador de cargas permite la conexión del cliente y pasa todas las solicitudes al backend, independientemente de si se puede establecer o no una cadena de confianza.

La prueba de posesión de la clave privada siempre se verifica cuando se presenta el certificado de cliente. Si el cliente no puede demostrar la posesión de la clave privada, se finalizará el protocolo de enlace TLS, incluso si el modo de validación del cliente permite un certificado de cliente no válido o faltante.
REJECT_INVALID: Rechaza la conexión si un cliente no proporciona un certificado o si falló la validación del certificado. En este modo, el balanceador de cargas finaliza la conexión del cliente si no puede establecer una cadena de confianza desde el certificado del cliente hasta el ancla de confianza.

Configura mTLS en el balanceador de cargas

A continuación, se proporciona una descripción general de alto nivel de los pasos clave que debes seguir para configurar la mTLS en tu balanceador de cargas:

Crea un recurso de configuración de confianza que incluya el ancla de confianza (certificado raíz) y los certificados intermedios que funcionen como raíces de confianza.
Vincula la configuración de confianza al recurso de autenticación de cliente (ServerTLSPolicy), que define el modo de validación del cliente de ALLOW_INVALID_OR_MISSING_CLIENT_CERT o REJECT_INVALID.
Adjunta el recurso de autenticación de clientes (ServerTLSPolicy) al recurso de proxy HTTPS de destino del balanceador de cargas.
Opcional: Puedes usar encabezados mTLS personalizados para pasar información sobre la conexión mTLS a un servicio de backend o a un mapa de URL.

Para obtener más información sobre esta configuración en detalle, consulta las siguientes guías:

Pasos para la validación del certificado de cliente

Cuando valida el certificado de cliente, el balanceador de cargas hace lo siguiente:

Verifica que el cliente posea la clave privada.

El cliente demuestra la posesión de la clave privada asociada con la clave pública en el certificado generando una firma durante el proceso de protocolo de enlace. El balanceador de cargas verifica esta firma con la clave pública del cliente. Si la verificación de firma falla, significa que el cliente no es el propietario del certificado. En ese caso, se finalizará el protocolo de enlace TLS, incluso si tu configuración permite un certificado de cliente no válido o faltante. No se registran errores para los balanceadores de cargas de aplicaciones externos globales, pero se registra un error de TLS en el campo proxyStatus para los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos.
Verifica la cadena de confianza.

El balanceador de cargas verifica la cadena de confianza entre el certificado de cliente y la configuración de confianza configurada. Las verificaciones de verificación incluyen lo siguiente:
- Los certificados de cliente, intermedio y raíz cumplen con los requisitos de los certificados.
- El campo de asunto del certificado superior coincide con el campo de emisor del certificado secundario. Esta verificación garantiza que la identidad (sujeto) del certificado superior sea la misma que la identidad que figura como emisor en el certificado secundario.
- El identificador de clave de asunto (SKID) del certificado superior coincide con el identificador de clave de autoridad (AKID) del certificado secundario. Esta coincidencia confirma que la autoridad raíz correcta emitió el certificado secundario y que se puede confiar en él porque se hace referencia a la clave pública de la raíz en el AKID para verificar la validez del certificado.
- El nombre alternativo de asunto (SAN) de un certificado secundario no vulnera el campo NameConstraints del certificado superior.
Nota: Los certificados de cliente autofirmados no forman una cadena de confianza válida y siempre se rechazan.
Reenvía la solicitud al backend.

Si la validación del certificado del cliente se realiza correctamente, la solicitud se reenvía al backend con encabezados mTLS personalizados.

Sin embargo, si la validación falla, la acción que se realiza depende del valor del modo de validación del cliente:
- ALLOW_INVALID_OR_MISSING_CLIENT_CERT: La solicitud se reenvía con encabezados mTLS personalizados que indican el motivo del error de validación. Para los balanceadores de cargas de aplicaciones internos entre regiones, los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones internos regionales, además de los encabezados mTLS personalizados, puedes configurar campos opcionales mTLS para verificar el motivo de la falla.
- REJECT_INVALID: Se finaliza la conexión y los errores se registran en Cloud Logging.

Encabezados mTLS personalizados que se pasan al backend

En la siguiente tabla, se muestran los encabezados personalizados de mTLS que se pasan al backend, tanto cuando el certificado de cliente pasa la validación como cuando falla. Si el certificado de cliente falla la validación, los encabezados personalizados se pasan al backend solo cuando el modo de validación del cliente se establece en ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Estado del certificado de cliente	Modo de validación del cliente	Encabezados personalizados
La cadena de certificados de cliente es demasiado larga (se incluyen más de 10 certificados intermedios con el certificado de cliente).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_exceeded_limit` `client_cert_sha256_fingerprint: <cert hash>`
Un cliente o certificado intermedio tiene un tamaño de clave RSA no válido. No se realiza ninguna validación. Las claves RSA pueden variar de 2048 a 4096 bits.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_invalid_rsa_key_size` `client_cert_sha256_fingerprint: <cert hash>`
Un cliente o un certificado intermedio usa una curva elíptica no compatible. No se realiza ninguna validación. Las curvas elípticas válidas son P-256 y P-384.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_elliptic_curve_key` `client_cert_sha256_fingerprint: <cert hash>`
Un cliente o un certificado intermedio usa un algoritmo que no es de RSA ni ECEC. No se realiza ninguna validación.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_key_algorithm` `client_cert_sha256_fingerprint: <cert hash>`
La PKI que se usará para la validación tiene más de diez certificados intermedios que comparten la misma información de la entidad y la clave pública de la entidad. No se realiza ninguna validación.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_pki_too_large` `client_cert_sha256_fingerprint: <cert hash>`
Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombres.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_max_name_constraints_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
El certificado de cliente no tiene la extensión `Extended Key Usage (EKU)` que incluye `clientAuth`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_invalid_eku` `client_cert_sha256_fingerprint: <cert hash>`
Se excede el límite de tiempo mientras se intenta validar la cadena de certificados.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_timed_out` `client_cert_sha256_fingerprint: <cert hash>`
Se alcanza el límite de iteración o profundidad mientras se intenta validar la cadena de certificados. La profundidad máxima de una cadena de certificados es de diez, incluidos los certificados raíz y de cliente. La cantidad máxima de iteraciones es de 100 (certificados examinados para validar la cadena de certificados de cliente).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_search_limit_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
Configuraste mTLS sin configurar un recurso `TrustConfig`. No se puede realizar ninguna validación, pero el hash del certificado se reenvía al backend.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_not_performed` `client_cert_sha256_fingerprint: <cert hash>`
Sin certificado de cliente.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: false` `client_cert_chain_verified: false` `client_cert_error: client_cert_not_provided` `client_cert_sha256_fingerprint: <empty>`
El certificado de cliente falla con la validación del recurso `TrustConfig`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_failed` `client_cert_sha256_fingerprint: <cert hash>`
El certificado de cliente pasa la validación del verificador de certificados.	No aplicable	`client_cert_present: true` `client_cert_chain_verified: true` `client_cert_error: <empty>` `client_cert_sha256_fingerprint: <cert hash>` `client_cert_serial_number: <serial_number>` `client_cert_valid_not_before: <date>` `client_cert_valid_not_after: <date>` `client_cert_uri_sans: <list>` `client_cert_dnsname_sans: <list>` `client_cert_issuer_dn: <issuer>` `client_cert_subject_dn: <subject>` `client_cert_leaf: <certificate>` `client_cert_chain: <list>`

Manejo de errores y registro

Los balanceadores de cargas de aplicaciones proporcionan capacidades de registro detalladas que te permiten supervisar la validación de certificados de cliente, identificar posibles problemas y solucionar problemas de conexión. En esta sección, se describen los diferentes tipos de errores que pueden ocurrir durante la validación de mTLS y cómo se registran.

Errores registrados en el modo `REJECT_INVALID`

Si la validación del certificado de cliente falla y el modo de validación del cliente está configurado como REJECT_INVALID, se finalizará la conexión y los errores se registrarán en Cloud Logging. Estos errores se describen en la siguiente tabla.

Estado del certificado de cliente	Error registrado
La cadena de certificados de cliente es demasiado larga (se incluyen más de 10 certificados intermedios con el certificado de cliente).	`client_cert_chain_exceeded_limit`
Un cliente o certificado intermedio tiene un tamaño de clave RSA no válido. No se realiza ninguna validación. Las claves RSA pueden variar de 2048 a 4096 bits.	`client_cert_invalid_rsa_key_size`
Un cliente o un certificado intermedio usa una curva elíptica no compatible. No se realiza ninguna validación. Las curvas válidas son P-256 y P-384.	`client_cert_unsupported_elliptic_curve_key`
Un cliente o un certificado intermedio usa un algoritmo que no es de RSA ni ECEC. No se realiza ninguna validación.	`client_cert_unsupported_key_algorithm`
La PKI que se usará para la validación tiene más de diez certificados intermedios que comparten la misma información de la entidad y la clave pública de la entidad. No se realiza ninguna validación.	`client_cert_pki_too_large`
Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombres.	`client_cert_chain_max_name_constraints_exceeded`
El certificado de cliente no tiene una extensión `Extended Key Usage (EKU)` que incluya `clientAuth`.	`client_cert_chain_invalid_eku`
Se excede el límite de tiempo mientras se intenta validar la cadena de certificados.	`client_cert_validation_timed_out`
Se alcanza el límite de iteración o profundidad mientras se intenta validar la cadena de certificados. La profundidad máxima de una cadena de certificados es de diez, incluidos los certificados raíz y de cliente. La cantidad máxima de iteraciones es 100 (certificados examinados para validar la cadena del certificado de cliente).	`client_cert_validation_search_limit_exceeded`
Configuraste mTLS sin configurar un recurso `TrustConfig`.	`client_cert_validation_not_performed`
El cliente no proporcionó el certificado solicitado durante el protocolo de enlace.	`client_cert_not_provided`
El certificado de cliente falla la validación con el recurso `TrustConfig`.	`client_cert_validation_failed`

Errores registrados para conexiones cerradas

Cuando el modo de validación del cliente se establece en ALLOW_INVALID_OR_MISSING_CLIENT_CERT o REJECT_INVALID, ciertos errores generan conexiones cerradas y se registran en Cloud Logging. Estos errores se describen en la siguiente tabla.

Estado del certificado de cliente	Solicitud	Error registrado
El certificado de cliente falla en la coincidencia de firma durante el protocolo de enlace.	Finaliza el protocolo de enlace SSL	Ninguna
El servicio no puede realizar la validación de la cadena de certificados.	Finalizar conexión	`client_cert_validation_unavailable`
Cadena de certificados de validación de errores internos.	Finalizar conexión	`client_cert_validation_internal_error`
No se encontró la `TrustConfig` coincidente.	Finalizar conexión	`client_cert_trust_config_not_found`
La carga útil del certificado de cliente (incluidos los certificados intermedios) es demasiado grande (más de 16 KB).	Finalizar conexión	`client_cert_exceeded_size_limit`

Si el registro está habilitado en el servicio de backend, puedes ver los errores registrados de las conexiones cerradas durante la validación del certificado de cliente mTLS.

Limitaciones

El balanceador de cargas no realiza verificaciones de revocación en los certificados de cliente.
Los balanceadores de cargas de aplicaciones te permiten subir una configuración de confianza con un solo almacén de confianza que contenga como máximo 100 anclas de confianza y 100 certificados intermedios, y 500 certificados que se agregan a una lista de entidades permitidas. Todos los certificados intermedios no deben tener más de tres certificados que compartan la misma información de la entidad y la clave pública de la entidad. Para obtener más información, consulta Cuotas y límites.
La profundidad máxima de una cadena de certificados es de diez, incluidos los certificados raíz y de cliente. La cantidad máxima de veces que se pueden evaluar los certificados intermedios cuando se intenta compilar la cadena de confianza es 100. Para obtener más información, consulta Cuotas y límites.
Las claves de los certificados subidos y pasados del cliente están restringidas a lo siguiente:
- Las claves RSA pueden variar de 2048 a 4096 bits. Para obtener más información, consulta Cuotas y límites.
- Las claves ECDSA pueden usar las curvas P-256 o P-384.
La cadena de certificados aceptados que se recibe del cliente tiene un límite de hasta 16 KB y 10 certificados. Para obtener más información, consulta Cuotas y límites.
Los certificados raíz que se usan para la validación no pueden contener más de 10 restricciones de nombres. Para obtener más información, consulta Cuotas y límites.