Información general sobre TLS mutuo

TLS mutuo (mTLS) es un protocolo estándar del sector para la autenticación mutua entre un cliente y un servidor. De esta forma, tanto el cliente como el servidor se autentican entre sí verificando que cada uno tiene un certificado válido emitido por una autoridad de certificación (AC) de confianza. A diferencia de TLS estándar, donde solo se autentica el servidor, mTLS requiere que el cliente y el servidor presenten certificados, lo que confirma las identidades de ambas partes antes de establecer la comunicación.

mTLS está configurado en el recurso de proxy HTTPS de destino de todos los balanceadores de carga de aplicación:

• Balanceador de carga de aplicación externo global
• Balanceador de carga de aplicación clásico
• Balanceador de carga de aplicación externo regional
• Balanceador de carga de aplicación interno regional
• Balanceador de carga de aplicación interno entre regiones

La autenticación mutua de TLS 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 de certificación (CA). mTLS para balanceadores de carga admite las siguientes funciones:

• Verifica que el cliente que presenta el certificado tiene su clave privada.

• Valida los certificados de cliente en uno de los dos modos:

  • Rechazar 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 que faltan: ofrece flexibilidad al enviar todas las solicitudes al backend, aunque falte un certificado de cliente o no sea válido.

• Valida los certificados de cliente con una ancla de PKI subida (certificado raíz) y añade varias anclas por separado para migrar de una PKI antigua a una nueva sin tiempo de inactividad.

• Proporciona certificados intermedios adicionales para ayudar a crear la ruta de validación del certificado de cliente con las anclas de PKI especificadas (certificados raíz). Estos certificados intermedios permiten que mTLS funcione con clientes que no proporcionan la cadena de certificados completa.

• Genera y envía una huella digital del certificado al backend como encabezado de solicitud personalizado.

• Transfiere al backend los campos seleccionados extraídos del certificado mediante encabezados personalizados.

• Transfiere el resultado de la validación y los errores de validación al backend mediante encabezados personalizados.

Requisitos de los certificados

Al configurar certificados para mTLS, asegúrate de que cumplan estos requisitos:

• Las herramientas de criptografía modernas son la base de la autenticación mTLS. Los certificados deben usar los algoritmos RSA o ECDSA para el intercambio de claves. Los algoritmos de cifrado con hash deben usar SHA-256 o una función de hash criptográfica más segura. No se admiten algoritmos hash como MD4, MD5 y SHA-1.
• En el caso de los certificados de cliente (hoja):
  • La extensión Restricciones básicas no debe contener CA=true.
  • La extensión Uso adicional de claves debe contener clientAuth.
  • La extensión Uso mejorado de claves no debe contener los campos codeSigning, timeStamping ni OCSPSigning.
  • El certificado no debe haber caducado.
  • El certificado de cliente no puede ser un certificado autofirmado.
• En el caso de los certificados raíz e intermedios:
  • La extensión Restricciones básicas debe contener CA=true.
  • La extensión Uso de clave debe tener el valor keyCertSign.
  • La extensión Uso mejorado de claves debe contener el campo clientAuth.
  • El certificado no debe haber caducado.

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, opcionalmente, uno o varios certificados intermedios. Cuando el balanceador de carga 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 ofrece un breve resumen de los distintos recursos que debe configurar para configurar mTLS en el balanceador de carga:

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

  Si necesitas usar un certificado que se ha firmado automáticamente, ha caducado o no es válido por otro motivo, o bien si no tienes acceso a los certificados raíz e intermedios, puedes añadirlo a la configuración de confianza en el campo allowlistedCertificates. No necesitas un almacén de confianza para añadir un certificado a una lista de permitidas.

  Añadir un certificado a la lista de permitidos significa que siempre se considerará válido siempre que se pueda analizar, se demuestre la 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 autoridad de certificación (AC) intermedios 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 CA se identifica mediante el ancla de confianza (certificado raíz) del balanceador de carga o los certificados de CA intermedia.

  Puede subir los siguientes tipos de certificados raíz e intermedios al almacén de confianza:

  • Certificados emitidos por ACs de terceros que elijas.
  • Certificados emitidos por CAs privadas que controles, tal como se describe en el artículo Configurar TLS mutuo con una CA privada.
  • Certificados proporcionados por el usuario, tal como se describe en Configurar TLS mutuo con certificados proporcionados por el usuario.

• Autenticación de cliente (también conocida como ServerTLSPolicy). Especifica el modo de validación de cliente y el recurso de configuración de confianza que se va a usar al validar los certificados de cliente. Cuando el cliente presenta un certificado no válido o ningún certificado al balanceador de carga, el modo de validación del cliente especifica cómo se gestiona la conexión del cliente. Puedes especificar todos los parámetros relacionados con la autenticación mTLS en las políticas TLS del servidor. El recurso ClientAuthentication (ServerTLSPolicy) se adjunta al recurso de proxy HTTPS de destino.

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

Mundial

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

TLS mutuo con componentes del balanceador de carga de aplicación externo global (haz clic para ampliar).

regional

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

TLS mutuo con componentes del balanceador de carga de aplicación interno regional (haz clic para ampliar).

Modo de validación de cliente

Cuando el cliente presenta un certificado no válido o no presenta ningún certificado al balanceador de carga, el atributo clientValidationMode del recurso de autenticación de cliente (ServerTLSPolicy) especifica cómo gestiona el balanceador de carga 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 del cliente aunque no se haya podido validar el certificado de cliente o no se haya presentado ningún certificado de cliente. En este modo, el balanceador de carga permite la conexión del cliente y transfiere 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 se comprueba siempre que se presenta el certificado de cliente. Si el cliente no puede demostrar que tiene la clave privada, el handshake TLS se termina aunque el modo de validación del cliente permita que el certificado de cliente no sea válido o falte.

• REJECT_INVALID. Rechaza la conexión si un cliente no proporciona un certificado o si la validación del certificado ha fallado. En este modo, el balanceador de carga finaliza la conexión del cliente si no puede establecer una cadena de confianza desde el certificado de cliente hasta la ancla de confianza.

Configurar mTLS en el balanceador de carga

A continuación, se muestra un resumen de los pasos clave que debes seguir para configurar mTLS en tu balanceador de carga:

1. Crea un recurso de configuración de confianza que incluya el ancla de confianza (certificado raíz) y los certificados intermedios que actúan como raíces de confianza.

2. Vincula la configuración de confianza al recurso Client Authentication (ServerTLSPolicy), que define el modo de validación del cliente ALLOW_INVALID_OR_MISSING_CLIENT_CERT o REJECT_INVALID.

3. Asocia el recurso de autenticación de cliente (ServerTLSPolicy) al recurso de proxy HTTPS de destino del balanceador de carga.

4. Opcional: Puedes usar encabezados mTLS personalizados para transferir información sobre la conexión mTLS a un servicio de backend o a un mapa de URLs.

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

• Configurar TLS mutuo con certificados proporcionados por el usuario
• Configurar TLS mutuo con una AC privada

Pasos para validar el certificado de cliente

Al validar el certificado de cliente, el balanceador de carga hace lo siguiente:

1. Verifica que el cliente tiene la clave privada.

   El cliente demuestra que tiene la clave privada asociada a la clave pública del certificado generando una firma durante el proceso de handshake. El balanceador de carga verifica esta firma con la clave pública del cliente. Si la verificación de la firma falla, significa que el cliente no es el propietario del certificado. En ese caso, la negociación de TLS se termina aunque tu configuración permita que el certificado de cliente no sea válido o falte. No se registran errores en los balanceadores de carga de aplicación externos globales, pero sí en el campo proxyStatus de los balanceadores de carga de aplicación externos regionales y de los balanceadores de carga de aplicación internos.

2. Verifica la cadena de confianza.

   El balanceador de carga verifica la cadena de confianza entre el certificado de cliente y la configuración de confianza configurada. Las comprobaciones de verificación incluyen lo siguiente:

   • Los certificados de cliente, intermedio y raíz cumplen los requisitos de los certificados.
   • El campo de asunto del certificado principal coincide con el campo de emisor del certificado secundario. Esta verificación asegura que la identidad (sujeto) del certificado principal sea la misma que la identidad que figura como emisor en el certificado secundario.
   • El identificador de clave de la entidad receptora (SKID) del certificado principal coincide con el identificador de clave de la autoridad (AKID) del certificado secundario. Esta coincidencia confirma que la autoridad raíz correcta ha emitido 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 del sujeto (SAN) de un certificado secundario no infringe el campo NameConstraints del certificado principal.
   Nota: Los certificados de cliente autofirmados no forman una cadena de confianza válida y siempre se rechazan.

3. Reenvía la solicitud al backend.

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

   Sin embargo, si la validación falla, la acción que se lleve a cabo dependerá 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. En el caso de los balanceadores de carga de aplicaciones internos entre regiones, los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales, además de los encabezados mTLS personalizados, puedes configurar campos opcionales de mTLS para comprobar el motivo del fallo.

   • REJECT_INVALID: La conexión se termina y los errores se registran en Cloud Logging.

Encabezados mTLS personalizados transferidos al backend

En la siguiente tabla se muestran las variables de encabezado de mTLS personalizadas que se pueden enviar al backend, tanto si el certificado de cliente supera la validación como si no. Si el certificado de cliente no supera la validación, las solicitudes se envían al backend solo cuando el modo de validación del cliente se establece en ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Estas variables también se pueden definir en un mapa de URLs.

Estado del certificado de cliente	Modo de validación de cliente	Cabeceras personalizadas
La cadena de certificados de cliente es demasiado larga (se han incluido 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 un certificado intermedio tiene un tamaño de clave RSA no válido. No se realiza ninguna validación. Las claves RSA pueden tener entre 2048 y 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 está usando una curva elíptica no admitida. 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 RSA ni ECDSA. 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 va a usar para la validación tiene más de diez certificados intermedios que comparten el mismo asunto y la misma información de clave pública del asunto. 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 ha superado el tiempo límite al intentar 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 ha alcanzado el límite de profundidad o de iteración al intentar 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. El número máximo de iteraciones es 100 (certificados examinados para validar la cadena de certificados del 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>
Has configurado 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>
No hay ningún 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 no se valida con el 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 supera 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>

Analizar los valores de las variables de encabezado personalizadas que se transfieren al backend

Algunos valores de variables de encabezado mTLS personalizadas son representaciones de cadenas codificadas en base64 de datos de certificados binarios con reglas de codificación distinguidas (DER). Puedes decodificar cadenas codificadas en Base64 con las herramientas o bibliotecas de software que elijas. A continuación, se muestran algunos ejemplos:

• Los sistemas macOS y Linux pueden usar la herramienta de línea de comandos base64, que es una utilidad principal incluida en ambos sistemas operativos. Para decodificar cadenas codificadas en Base64 con la utilidad base64, pasa la cadena codificada como entrada estándar al comando base64 y usa la marca -d para decodificar la cadena de la siguiente manera:

  echo BASE_64_ENCODED_STRING | base64 -d
  

• Python incluye el módulo base64, que se puede usar para decodificar cadenas codificadas en Base64 de la siguiente manera:

  import base64
  encoded_string=BASE_64_ENCODED_STRING
  decoded_string=base64.b64decode(encoded_string).decode()
  print(decoded_string) # Note that a newline character (\n) is added to the end of the string.
  

Gestión de errores y registro

Los balanceadores de carga de aplicaciones ofrecen funciones de registro detalladas que le permiten monitorizar la validación de certificados de cliente, identificar posibles problemas y solucionar problemas de conexión. En esta sección se describen los distintos tipos de errores que pueden producirse durante la validación de mTLS y cómo se registran.

Errores registrados en el modo REJECT_INVALID

Si falla la validación del certificado de cliente y el modo de validación de cliente se ha definido como REJECT_INVALID, se terminará 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 han incluido más de 10 certificados intermedios con el certificado de cliente).	client_cert_chain_exceeded_limit
Un cliente o un certificado intermedio tiene un tamaño de clave RSA no válido. size. No se realiza ninguna validación. Las claves RSA pueden tener entre 2048 y 4096 bits.	client_cert_invalid_rsa_key_size
Un cliente o un certificado intermedio está usando una curva elíptica no admitida. 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 está usando un algoritmo que no es RSA o ECDSA. No se realiza ninguna validación.	client_cert_unsupported_key_algorithm
La PKI que se va a usar para la validación tiene más de diez certificados intermedios que comparten el mismo asunto y la misma información de clave pública del asunto. 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 ha superado el tiempo límite al intentar validar la cadena de certificados.	client_cert_validation_timed_out
Se ha alcanzado el límite de profundidad o iteración al intentar 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. El número máximo de iteraciones es 100 (certificados examinados para validar la cadena de certificados del cliente).	client_cert_validation_search_limit_exceeded
Has configurado mTLS sin configurar un recurso TrustConfig.	client_cert_validation_not_performed
El cliente no ha proporcionado el certificado solicitado durante la negociación.	client_cert_not_provided
El certificado de cliente no supera la validación con el recurso TrustConfig.	client_cert_validation_failed

Errores registrados de conexiones cerradas

Cuando el modo de validación de clientes se define como ALLOW_INVALID_OR_MISSING_CLIENT_CERT o REJECT_INVALID, determinados errores provocan que se cierren las conexiones y se registren en Cloud Logging. Estos errores se describen en la siguiente tabla.

Estado del certificado de cliente	Solicitud	Error registrado
El certificado de cliente no coincide con la firma durante el handshake.	Finalizar el handshake de SSL	Ninguno
El servicio no puede realizar la validación de la cadena de certificados.	Finalizar conexión	client_cert_validation_unavailable
Error interno al validar la cadena de certificados.	Finalizar conexión	client_cert_validation_internal_error
No se ha encontrado ningún TrustConfig que coincida.	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 backend, puedes ver los errores registrados de las conexiones cerradas durante la validación del certificado de cliente mTLS.

Limitaciones

• El balanceador de carga no realiza comprobaciones de revocación en los certificados de cliente.

• Los balanceadores de carga de aplicaciones te permiten subir una configuración de confianza con un solo almacén de confianza, que contiene como máximo 200 anclas de confianza y certificados intermedios (el número de certificados intermedios está limitado a 100) y 500 certificados que se añaden a una lista de permitidos. Todos los certificados intermedios no deben tener más de tres certificados que compartan la misma información de clave pública y de asunto. 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. El número máximo de veces que se pueden evaluar los certificados intermedios al intentar crear la cadena de confianza es 100. Para obtener más información, consulta Cuotas y límites.

• Las claves de los certificados subidos y transferidos desde el cliente solo pueden ser de los siguientes tipos:

  • Las claves RSA pueden tener entre 2048 y 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 aceptada recibida del cliente no puede superar los 16 KB ni los 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.

• La capa 1 de Google Front Ends (GFEs) aplica un tiempo de espera no configurable de 10 segundos para que el cliente presente su certificado durante el handshake TLS. En condiciones de carga máxima, este tiempo de espera puede ser más corto. Los clientes deben completar la presentación del certificado en este periodo para establecer una conexión mTLS correctamente.

Siguientes pasos

• Configurar TLS mutuo con certificados proporcionados por el usuario

• Configurar TLS mutuo con una AC privada

• Variables que pueden aparecer en el valor del encabezado