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 tanto el cliente como el servidor se autentiquen entre sí verificando 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, lo que confirma 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). mTLS para balanceadores de cargas admite las siguientes funciones:
Verificar que el cliente que presenta el certificado posea su clave privada
Valida los certificados de cliente con uno de los modos de validación de clientes.
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 de 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 con encabezados personalizados.
Pasa el resultado de la validación y cualquier error de validación al backend con encabezados personalizados.
Requisitos del certificado
Cuando configures certificados para mTLS, asegúrate de que cumplan con estos 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.
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,timeStampingoOCSPSigning.El certificado no debe estar vencido.
El certificado de 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 establecer la mTLS en 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 que se haya autofirmado, que haya vencido o que no sea válido, o si no tienes acceso a los certificados raíz y de nivel intermedio, 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 el certificado 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 en el campo SAN del certificado.
Almacén de confianza. Contiene los certificados de ancla de confianza y de la autoridad certificadora (CA) intermedia que se usan para establecer una cadena de confianza y validar el certificado de cliente. Una CA se usa para emitir certificados de confianza para el cliente. La AC se identifica con el ancla de confianza del balanceador de cargas (certificado raíz) o los certificados de la AC intermedios.
Puedes subir los siguientes tipos de certificados raíz e 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 clientes (también conocida como
ServerTLSPolicy). Especifica el modo de validación de clientes 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 del 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.
Modos de validación del cliente
El atributo clientValidationMode
del recurso de autenticación de clientes
(ServerTLSPolicy) especifica cómo el balanceador de cargas controla la
conexión del cliente. El modo determina si los certificados de cliente no válidos o faltantes
se rechazan de forma estricta (REJECT_INVALID),
se rechazan, excepto por verificaciones específicas de X.509 relajadas
(ALLOW_VALIDATION_RELAXATIONS), o se reenvían al backend
(ALLOW_INVALID_OR_MISSING_CLIENT_CERT).
Los diferentes modos de validación del cliente son los siguientes:
- Permite certificados de cliente no válidos o faltantes (
ALLOW_INVALID_OR_MISSING_CLIENT_CERT) - Rechaza los certificados de cliente no válidos (
REJECT_INVALID) - Permitir flexibilizaciones de validación (
ALLOW_VALIDATION_RELAXATIONS)
Permite un certificado de cliente no válido o faltante
El modo ALLOW_INVALID_OR_MISSING_CLIENT_CERT permite la conexión desde el cliente,
incluso si el certificado de cliente no se valida o el cliente
no presenta un certificado. En este modo, el balanceador de cargas permite
la conexión desde el 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, el protocolo de enlace TLS se finaliza, incluso si el modo de validación del cliente permite un certificado de cliente no válido o faltante.
Rechazar un certificado de cliente no válido
El modo 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 de cliente hasta el ancla de confianza.
Permitir flexibilizaciones de validación
El modo ALLOW_VALIDATION_RELAXATIONS aplica la validación del certificado de cliente,
pero permite flexibilizar las verificaciones de validación específicas,
por ejemplo, durante una migración en la que los certificados de cliente heredados no cumplen con todos
los requisitos estrictos de los certificados. Si tienes un
recurso ServerTLSPolicy existente en modo REJECT_INVALID, puedes actualizarlo
para usar el modo ALLOW_VALIDATION_RELAXATIONS y especificar la lista de
flexibilizaciones de validación que deseas permitir.
Puedes especificar uno o más de los siguientes valores en el
campo clientValidationRelaxations:
ALLOW_MISSING_EKU: Permite que el certificado de cliente omita la extensión de uso extendido de la clave (EKU).ALLOW_MISSING_EKUsolo permite un certificado que no tenga ninguna extensión de EKU; no ignora una extensión de EKU que esté presente con el propósito incorrecto. Por ejemplo, si la extensión de EKU está presente en el certificado de cliente, debe incluir el propósito de la claveclientAuth(OID 1.3.6.1.5.5.7.3.2), como se especifica en los requisitos del certificado. Si el certificado tiene una extensión de EKU que indica otro propósito (comoserverAuth), pero noclientAuth, se rechaza la conexión.ALLOW_SHA1_HASHING: Permite la validación de cadenas de certificados de cliente firmadas con resúmenes de mensajes SHA-1 heredados.ALLOW_EXPIRED_LEAF_CERTIFICATE: Permite la validación de un certificado de hoja de cliente vencido. El balanceador de cargas valida el certificado de hoja de cliente vencido como si la hora actual fuera un segundo antes del final de su período de validez (notAftermenos un segundo). Esto permite que el certificado de hoja del cliente pase la verificación de vencimiento. Esta flexibilización se aplica estrictamente al certificado de hoja del cliente y no a los certificados intermedios o raíz de la cadena. Los certificados de hoja de cliente que aún no son válidos (en los que la hora actual es anterior a la marca de tiemponotBefore) se siguen rechazando.
El modo ALLOW_VALIDATION_RELAXATIONS requiere un certificado de cliente y
valida la cadena de certificados con el recurso de configuración de confianza configurado,
mientras aplica las flexibilizaciones de validación específicas que indiques en el
campo clientValidationRelaxations.
Cuando seleccionas ALLOW_VALIDATION_RELAXATIONS, debes especificar al menos
una flexibilización de validación. Si seleccionas varias relajaciones, todas las seleccionadas
se aplican de forma simultánea. Siempre que el cliente proporcione un
certificado que sea válido después de aplicar las flexibilizaciones seleccionadas, el balanceador de cargas
aceptará la conexión. Por ejemplo, si configuras
ALLOW_MISSING_EKU y ALLOW_SHA1_HASHING, el balanceador de cargas acepta
conexiones de clientes que presentan certificados válidos que omiten
la extensión de uso extendido de la clave (EKU) y usan el algoritmo de hash SHA-1.
Si un cliente no proporciona un certificado o si la validación del certificado falla por cualquier motivo que no esté cubierto por las flexibilizaciones configuradas, el balanceador de cargas finaliza la conexión y registra el error en Cloud Logging.
Google Cloud recomienda usar las relajaciones de validación solo como una solución temporal
durante las migraciones de certificados. Usar ALLOW_VALIDATION_RELAXATIONS
es más seguro que usar ALLOW_INVALID_OR_MISSING_CLIENT_CERT,
ya que el balanceador de cargas sigue aplicando todas las demás verificaciones de validación
y no requiere una lógica de validación personalizada en tu backend.
Configura mTLS en el balanceador de cargas
A continuación, se proporciona una descripción general de los pasos clave que debes seguir para configurar 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 funcionan 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.Adjunta el recurso de autenticación de cliente (
ServerTLSPolicy) al recurso de proxy HTTPS de destino del balanceador de cargas.Opcional: Puedes usar encabezados de mTLS personalizados para pasar información sobre la conexión de mTLS a un servicio de backend o un mapa de URLs.
Para obtener más información sobre esta configuración, consulta las siguientes guías:
- Configurar una TLS mutua con certificados proporcionados por el usuario
- Configura la TLS mutua con una CA privada
Pasos para la validación del certificado de cliente
Cuando se 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 la firma falla, significa que el cliente no es el propietario del certificado, en cuyo caso, el protocolo de enlace TLS se finaliza, 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
proxyStatuspara 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 validando el certificado de cliente con los certificados configurados en la configuración de confianza. El modo de validación del cliente determina si los certificados de cliente no válidos o faltantes se rechazan de forma estricta (
REJECT_INVALID), se rechazan, excepto por verificaciones específicas de X.509 relajadas (ALLOW_VALIDATION_RELAXATIONS), o se reenvían al backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).Las verificaciones también incluyen lo siguiente:
- Los certificados de cliente, intermedios y raíz cumplen con los requisitos de certificado.
- El campo de asunto del certificado superior coincide con el campo de entidad emisora del certificado secundario. Esta verificación garantiza que la identidad (asunto) del certificado superior sea la misma que la identidad que aparece 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 el certificado secundario fue emitido por la autoridad raíz correcta 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
NameConstraintsen el certificado superior.
Reenvía la solicitud al backend.
Si la validación del certificado de cliente se realiza correctamente, la solicitud se reenvía al backend con encabezados de 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 de 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 de mTLS para verificar el motivo de la falla.REJECT_INVALIDyALLOW_VALIDATION_RELAXATIONS: 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 las variables de encabezado de mTLS personalizadas que están disponibles para pasarse al backend, tanto cuando el certificado de cliente pasa la validación como cuando falla. Si el certificado de cliente falla la validación,
las solicitudes se pasan 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 configurar en el mapa de URLs.
| 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
|
|
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 ser de 2,048 a 4,096 bits. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
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
|
|
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
|
|
La PKI que se usará para la validación tiene más de diez certificados intermedios que comparten la misma información del sujeto y de la información de clave pública del sujeto. No se realiza ninguna validación. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombres. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
El certificado de cliente no tiene
una extensión |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| Se excede el límite de tiempo mientras se intenta validar la cadena de certificados. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
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
|
|
Configuraste mTLS sin configurar un recurso No se puede realizar ninguna validación, pero el hash del certificado se reenvía al backend. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| Sin certificado de cliente. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
El certificado de cliente falla con la validación del recurso TrustConfig.
|
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| El certificado de cliente pasa la validación del verificador de certificados. | No aplicable |
client_cert_error: <empty>
|
Analiza los valores de las variables de encabezado personalizadas que se pasan al backend
Algunos valores de variables de encabezado de mTLS personalizados son representaciones de cadenas codificadas en Base64 de datos de certificados binarios de reglas de codificación distinguidas (DER). Puedes decodificar cadenas codificadas en Base64 con las herramientas o bibliotecas de software que elijas. Estos son 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 utilidadbase64, pasa la cadena codificada como entrada estándar al comandobase64y usa la marca-dpara 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.
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 los modos REJECT_INVALID y ALLOW_VALIDATION_RELAXATIONS
Si la validación del certificado de cliente falla y el modo de validación del cliente se establece en REJECT_INVALID o ALLOW_VALIDATION_RELAXATIONS, la conexión se finaliza y los errores se registran 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 ser de 2,048 a 4,096 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 del sujeto y de la información de clave pública del sujeto. 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. |
|
El certificado de cliente no tiene una extensión
|
|
| 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 se configura el modo de validación del cliente, 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 ejecutar una consulta para ver los registros de la validación del certificado de cliente de 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 contiene como máximo 200 anclas de confianza y certificados intermedios combinados (la cantidad de certificados intermedios se limita a 100) 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 ser de 2,048 a 4,096 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.
Los Google Front Ends (GFE) de capa 1 aplican un tiempo de espera no configurable de 10 segundos para que el cliente presente su certificado durante el protocolo de enlace TLS. En momentos de carga máxima, este tiempo de espera puede ser más corto. Los clientes deben completar la presentación del certificado dentro de este período para establecer correctamente una conexión mTLS.