Descripción general de TLS autenticado y mTLS del backend

Cuando un balanceador de cargas se conecta a backends que están dentro de Google Cloud, el balanceador de cargas acepta cualquier certificado que presenten los backends. En estos casos, el balanceador de cargas no realiza ninguna validación de certificados.

Con la TLS con autenticación de backend o la autenticación de backend, el balanceador de cargas puede verificar la identidad de los backends a los que se conecta. Además, con la mTLS de backend, el balanceador de cargas puede demostrar su identidad a los backends con un certificado TLS de cliente.

En el siguiente diagrama, se muestra la diferencia entre el mTLS de frontend y el de backend, y se destaca el rol del balanceador de cargas en cada caso. En mTLS de frontend, el balanceador de cargas actúa como el servidor y verifica la identidad del cliente. En la mTLS de backend, el balanceador de cargas actúa como el cliente y demuestra su identidad al backend.

mTLS de frontend y backend
mTLS de frontend y backend (haz clic para ampliar).

La mTLS funciona de forma independiente en el frontend y el backend. Puedes configurar mTLS en el frontend, el backend o ambos.

En este documento, se proporciona una descripción general de la TLS con autenticación de backend y la mTLS de backend. Para obtener más información sobre la mTLS de frontend, consulta la Descripción general de la TLS mutua.

La TLS con autenticación de backend y la mTLS de backend se pueden configurar en el recurso de servicio de backend de los balanceadores de cargas de aplicaciones externos globales.

Funciones

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 (CA). La TLS autenticada por el backend y la mTLS del backend agregan las siguientes capacidades a los balanceadores de cargas de aplicaciones:

  • El balanceador de cargas puede validar los certificados que presentan los backends en función de tus propias entidades de certificación. Puedes subir varias entidades de certificación para habilitar una migración sin problemas de una PKI anterior a una nueva sin tiempo de inactividad.

  • El balanceador de cargas puede validar los certificados TLS de los servidores de backend con las raíces de confianza públicas (PKI web).

  • Puedes configurar certificados intermedios además de tus anclajes de confianza para ayudar a construir la ruta de validación de certificados de backend. El uso de certificados intermedios significa que tus servidores de backend no necesitan proporcionar la cadena de certificados completa.

  • Puedes configurar un nombre de host de indicación de nombre del servidor (SNI) de TLS para tu servicio de backend. Durante el protocolo de enlace TLS, el balanceador de cargas incluye este nombre de host de SNI en el mensaje ClientHello que envía al backend. Luego, el backend responde con su certificado TLS, y el balanceador de cargas verifica que al menos uno de los campos de nombre alternativo del sujeto (SAN) de este certificado coincida con el nombre de host o con cualquiera de los campos de SAN configurados para el servicio de backend.

  • Puedes configurar el servicio de backend del balanceador de cargas para que use mTLS, de modo que el balanceador de cargas pueda demostrar su identidad a los backends. Esta autenticación se lleva a cabo con un certificado de cliente (balanceador de cargas) que el balanceador de cargas presenta al backend.

Requisitos del certificado

Cuando configures certificados para la autenticación de backend con TLS y la mTLS de backend, asegúrate de que cumplan con estos requisitos:

  • Las herramientas de criptografía modernas son 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 potente. No se admiten algoritmos de hash como MD4, MD5 y SHA-1.

  • Los certificados de servidor hoja que proporciona el backend tienen los siguientes requisitos:

  • En el caso de los certificados de cliente de hoja (balanceador de cargas) que se usan en mTLS de backend, el certificado debe ser un recurso de certificado del Administrador de certificados. El alcance de este certificado debe ser client-auth, lo que indica que se usa como certificado de cliente en mTLS de backend.

  • Los certificados raíz e intermedios que se usan con la TLS autenticada por el backend tienen los siguientes requisitos:

Componentes clave de la TLS con autenticación de backend y la mTLS de backend

Con la TLS con autenticación de backend, el balanceador de cargas puede verificar la identidad de los backends a los que se conecta. Puedes configurar TLS autenticado de backend en un balanceador de cargas de HTTP(S) que use HTTPS o HTTP/2 como protocolo de servicio de backend. Si no configuras TLS con autenticación de backend, el balanceador de cargas aceptará cualquier certificado del backend. Con la mTLS de backend, también puedes configurar el balanceador de cargas para que presente su propio certificado de cliente al backend, que este puede usar para autenticar el balanceador de cargas.

Para configurar la autenticación de TLS del backend, debes hacer lo siguiente:

  • Crea un recurso de configuración de confianza.
  • Crea un recurso de configuración de autenticación de backend.
  • Actualiza el atributo de configuración de TLS en el servicio de backend y haz que apunte al recurso de configuración de autenticación de backend.

Para configurar la mTLS de backend, debes crear un certificado de cliente y adjuntarlo al recurso de configuración de autenticación de backend. No puedes adjuntar el certificado de cliente después de que se haya creado el recurso de configuración de autenticación de backend.

En el siguiente diagrama, se muestran los diferentes componentes, conectados al servicio de backend de un balanceador de cargas de aplicaciones, que habilitan TLS autenticado de backend y mTLS de backend.

Componentes de TLS con autenticación de backend y mTLS de backend.
Componentes de TLS con autenticación de backend y mTLS de backend (haz clic para ampliar).

La siguiente información proporciona una descripción general de los diferentes componentes que se usan para configurar la TLS con autenticación de backend y la mTLS de backend.

Configuración de confianza

Para autenticar los certificados de servidor que tu backend presenta al balanceador de cargas, este debe configurarse con certificados X.509 que establezcan una cadena de confianza para la entidad emisora del certificado del backend. Para configurar la configuración de confianza, usa un recurso TrustConfig, que expresa toda la configuración de confianza y contiene un solo almacén de confianza.

Un almacén de confianza encapsula un ancla de confianza (certificado raíz) y, de forma opcional, uno o más certificados intermedios. Un ancla de confianza es un certificado que representa una raíz de confianza. Un certificado de servidor válido debe mostrar una cadena de confianza que se remonte a alguna entidad de certificación raíz en el almacén de confianza.

Un certificado intermedio es un certificado que forma parte de una cadena de confianza que conduce a un ancla de confianza en el almacén de confianza. Se usa, junto con las AC intermedias adicionales incluidas en el certificado de hoja, para compilar la cadena de confianza durante el proceso de validación. Crear un certificado intermedio es opcional.

Si necesitas usar un certificado autofirmado, vencido, que no se encadena a una raíz de confianza especificada o que no pasó la validación, puedes agregarlo a una lista de entidades permitidas en la configuración de confianza. También es opcional crear un certificado autofirmado que se pueda agregar a una lista de entidades permitidas.

El almacén de confianza no contiene ninguna clave privada, ya que solo se necesitan los certificados para verificar una cadena de confianza.

Recurso de configuración de autenticación de backend

El recurso de configuración de autenticación de backend (BackendAuthenticationConfig), adjunto al servicio de backend del balanceador de cargas, habilita lo siguiente:

  • TLS con autenticación de backend (con la configuración de confianza y las raíces de confianza públicas)
  • mTLS de backend (con el certificado de cliente)

Para habilitar TLS con autenticación de backend y mTLS de backend, el recurso de configuración de autenticación de backend apunta a los siguientes recursos:

  • Configuración de confianza (trustConfig): Es la configuración de confianza adjunta que se usa para validar el certificado del servidor proporcionado por el backend.

  • Raíces de confianza públicas (wellKnownRoots): Indica si el balanceador de cargas confía en los certificados de servidor de backend que emiten las CA públicas, además de los certificados en los que confía la configuración de confianza. Para obtener más información, consulta Cómo usar raíces públicas de confianza.

  • Certificado del cliente (clientCertificate): Es el certificado del cliente que el balanceador de cargas usa para expresar su identidad al backend si la conexión al backend usa mTLS. En el caso de la TLS con autenticación de backend (autenticación de backend), este campo puede estar vacío, en cuyo caso el balanceador de cargas solo autentica el backend, pero no se autentica a sí mismo ante el backend.

Servicio de backend

Dentro del servicio de backend, el atributo tlsSettings apunta a los siguientes recursos para validar el certificado de backend.

  • Configuración de autenticación de backend (authenticationConfig)
  • Nombre de host de SNI (sni)
  • SAN aceptadas (subjectAltNames)

Los campos SNI (sni) y SAN (subjectAltNames) del atributo tlsSettings controlan cómo el balanceador de cargas valida el certificado del backend según los valores de SAN del certificado. Estos campos influyen en el proceso de validación, independientemente de si se configuró TLS con autenticación de backend.

Cuando se configura el campo SNI (tlsSettings.sni), el balanceador de cargas hace lo siguiente:

  • Envía el nombre de host de SNI al servidor de backend durante el protocolo de enlace TLS.
  • Verifica que el certificado TLS del backend incluya un SAN que coincida con el nombre de host de SNI.

De forma predeterminada, el balanceador de cargas verifica que el certificado TLS del backend incluya un SAN que coincida con el nombre de host de SNI. Sin embargo, si los SAN están configurados en el servicio de backend (tlsSettings.subjectAltNames), el balanceador de cargas hace lo siguiente:

  • Ignora el nombre de host de SNI para la verificación de SAN.
  • Verifica que el certificado TLS del backend incluya un SAN que coincida con uno de los SAN aceptados (subjectAltNames) configurados en el servicio de backend.

Certificado de cliente

Además de la TLS autenticada del backend (autenticación de backend), puedes configurar el servicio de backend de un balanceador de cargas para que use mTLS, de modo que el balanceador de cargas pueda demostrar su identidad al backend. Esta autenticación usa un certificado de cliente (balanceador de cargas) que el balanceador de cargas presenta al backend.

Para configurar mTLS de backend, debes hacer lo siguiente:

  • Crea un recurso de certificado de cliente que contenga el certificado de cliente (balanceador de cargas) y su clave privada.
  • Adjunta el certificado de cliente al recurso de configuración de autenticación de backend.

La mTLS de backend también es compatible con las identidades para cargas de trabajo administradas de Compute Engine cuando configuras certificados administrados a través de Certificate Manager. No se admiten certificados administrados por PKI públicas, y todos los certificados de cliente deben tener un alcance de client-auth y cumplir con los requisitos de los certificados.

Si el backend solicita un certificado de cliente, debe configurarse para aceptar el certificado de cliente. Si el backend rechaza la conexión del balanceador de cargas, este devuelve un código de estado HTTP 502 para las solicitudes que proxy y registra un estado genérico en Cloud Logging.

Configura TLS con autenticación de backend y mTLS de backend en el balanceador de cargas

Puedes configurar TLS con autenticación de backend y mTLS de backend en el balanceador de cargas con una PKI privada o raíces de confianza públicas.

Usa una PKI privada

A continuación, se proporciona una descripción general de alto nivel de los pasos clave que debes seguir para configurar la TLS autenticada de backend y la mTLS de backend en tu balanceador de cargas con certificados emitidos desde tu PKI privada. La PKI privada tiene la ventaja de estar completamente bajo tu control y aislada de los sistemas de PKI de Internet pública.

  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. Para configurar mTLS de backend, crea un certificado de cliente que contenga el certificado de cliente (balanceador de cargas) y su clave privada.

  3. Crea un recurso de configuración de autenticación de backend que haga referencia a la configuración de confianza. Si deseas configurar la mTLS de backend, el recurso de configuración de autenticación de backend hace referencia tanto a la configuración de confianza como al certificado de cliente.

  4. Adjunta el recurso de configuración de autenticación de backend al servicio de backend del balanceador de cargas.

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

Usa raíces de confianza públicas

Además de usar certificados emitidos desde tu PKI privada para habilitar TLS autenticado de backend, también puedes usar raíces públicas de confianza para validar el certificado de backend.

Para usar raíces de confianza públicas, no es necesario que crees una configuración de confianza ni que la adjuntes al recurso de configuración de autenticación de backend. En su lugar, debes establecer PUBLIC_ROOTS como un valor en el campo wellKnownRoots del recurso de configuración de autenticación de backend. Dicho esto, también puedes crear una configuración de confianza que incluya de forma explícita las raíces de tus certificados emitidos públicamente, además de los certificados en los que confía la configuración de confianza.

El parámetro de configuración PUBLIC_ROOTS usa un conjunto de CA raíz, similar al conjunto de CA raíz en las que confían los navegadores, que administra Google y puede cambiar con el tiempo. Esto presenta el riesgo de que tus certificados de backend dejen de ser válidos cuando cambien estas raíces. Si necesitas validar certificados emitidos públicamente, considera elegir una CA confiable y bien establecida, y una que use la firma cruzada intermedia para emitir tus certificados de backend y mitigar el riesgo de que venza o se revoque un certificado raíz.

Pasos para la validación del certificado del servidor

Cuando valida el certificado del servidor durante la autenticación de backend o la autenticación de TLS con autenticación de backend, el balanceador de cargas hace lo siguiente:

  1. Verifica que el servidor posea la clave privada del certificado.

    El servidor demuestra que posee la clave privada asociada al certificado que presenta al balanceador de cargas firmando un fragmento de información con su clave privada y enviándolo al balanceador de cargas como parte del mensaje CertificateVerify. Luego, el balanceador de cargas verifica esta firma con la clave pública del certificado del servidor. Si falla la verificación de la firma, significa que el servidor de backend no posee la clave privada correspondiente al certificado. En estos casos, el balanceador de cargas finaliza el protocolo de enlace TLS sin registrar ningún error.

  2. Verifica la cadena de confianza.

    Si la configuración de confianza incluye al menos un ancla de confianza o tiene el atributo wellKnownRoots establecido en PUBLIC_ROOTS, el balanceador de cargas intenta verificar una cadena de confianza entre el certificado del servidor y el ancla de confianza configurada. Las verificaciones incluyen lo siguiente:

    • El certificado del servidor, los certificados intermedios (si se proporcionan) y el certificado raíz configurado del backend cumplen con los requisitos de certificado.
    • Para todos los certificados de la cadena de confianza, el campo de asunto del certificado principal coincide con el campo de emisor del certificado secundario. Esta verificación ayuda a garantizar que la identidad (sujeto) del certificado principal sea la misma que la identidad que aparece como emisor en el certificado secundario.
    • Para todos los certificados de la cadena de confianza, el identificador de clave de asunto (SKID) del certificado principal 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. 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.

  3. Establece una conexión con el backend.

    Si la validación del certificado se realiza correctamente, el balanceador de cargas continúa con la conexión al backend.

    Sin embargo, si falla la validación del certificado, el balanceador de cargas finaliza la conexión con el backend, envía un código de estado HTTP 502 al cliente y registra el motivo de la finalización en Cloud Logging. En caso de un error de validación del certificado, las solicitudes entrantes posteriores hacen que el balanceador de cargas reinicie la conexión de backend.

    La conexión de backend también puede fallar si el servidor de backend rechaza la conexión. Con la mTLS de backend, esto puede ocurrir porque el certificado de cliente se considera no válido. Cuando falla la conexión al backend, el balanceador de cargas responde a las solicitudes proxy con un código de estado HTTP 502 y registra un motivo de error genérico en Cloud Logging.

Manejo y registro de errores

Los balanceadores de cargas de aplicaciones proporcionan capacidades de registro detalladas que te permiten supervisar la validación de certificados del servidor, 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.

Si falla la validación del certificado del servidor, se finaliza la conexión y los errores se registran en Cloud Logging. Estos errores se describen en la siguiente tabla.

Estado del certificado del servidor Error registrado
La cadena de certificados del servidor es demasiado larga (se incluyen más de 10 certificados intermedios con el certificado del servidor). server_cert_chain_exceeded_limit

Un servidor 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.

 server_cert_invalid_rsa_key_size

Un servidor 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.

 server_cert_unsupported_elliptic_curve_key

Un servidor o un certificado intermedio usa un algoritmo que no es de RSA ni ECEC.

No se realiza ninguna validación.

 server_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.

 server_cert_pki_too_large

Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombres.

server_cert_chain_max_name_constraints_exceeded

El certificado del servidor tiene un campo de extensión Extended Key Usage (EKU) , pero ese campo no incluye serverAuth.

server_cert_chain_invalid_eku
Se excede el límite de tiempo mientras se intenta validar la cadena de certificados. server_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 servidor. La cantidad máxima de iteraciones es 100 (certificados examinados para validar la cadena del certificado de servidor).

 server_cert_validation_search_limit_exceeded

Configuraste mTLS sin configurar un recurso TrustConfig.

 server_cert_validation_not_performed

El servidor no proporcionó el certificado solicitado durante el protocolo de enlace.

 server_cert_not_provided

No se pudo verificar el certificado del servidor con el recurso TrustConfig.

 ssl_certificate_verification_failed

El servicio no puede realizar la validación de la cadena de certificados.

 server_cert_validation_unavailable
Cadena de certificados de validación de errores internos. server_cert_validation_internal_error

No se encontró la TrustConfig coincidente.

 server_cert_trust_config_not_found
La carga útil del certificado de servidor (incluidos los certificados intermedios) es demasiado grande (más de 16 KB). server_cert_exceeded_size_limit

Limitaciones

  • La TLS con autenticación de backend y la mTLS de backend solo se pueden configurar para los balanceadores de cargas de aplicaciones externos globales. Los balanceadores de cargas de aplicaciones clásicos no admiten TLS autenticado por el backend ni mTLS del backend.

  • No se admiten TLS con autenticación de backend ni mTLS de backend para los siguientes tipos de backends:

    • Backends de NEG de Internet globales

    • Backends de App Engine

  • Para habilitar la mTLS del backend, también debes configurar la TLS autenticada del backend.

  • Si deseas habilitar la mTLS de backend, debes crear el certificado de cliente antes de configurar el recurso de configuración de autenticación de backend.

  • Las verificaciones de estado que usan los backends no implementan la autenticación TLS ni las capacidades de mTLS. Debes configurar los backends con extremos de verificación de estado que puedan responder a solicitudes HTTP o HTTPS.

  • El balanceador de cargas no pasa el nombre de host de SNI del cliente desde la conexión TLS de frontend cuando se conecta a un backend. Sin embargo, los backends pueden acceder al nombre de host de SNI del cliente a través de un encabezado de solicitud personalizado.

  • En el caso de mTLS de backend, las claves de los certificados de cliente están restringidas a lo siguiente:

    • Las claves RSA pueden variar de 2048 a 4096 bits.
    • Las claves ECDSA pueden usar las curvas P-256 o P-384.

  • La TLS con autenticación de backend no admite verificaciones de revocación de certificados.

Cuotas y límites

  • Un solo almacén de confianza puede contener hasta 200 anclas de confianza y certificados intermedios combinados, con un límite independiente de 100 para los certificados intermedios. No más de tres certificados intermedios pueden compartir la misma información de la entidad y la clave pública de la entidad.

  • La profundidad máxima de una cadena de certificados es de 10 certificados, incluidos los certificados raíz y de hoja. La cantidad máxima de certificados intermedios que se pueden evaluar cuando se intenta compilar la cadena de confianza es 100.

  • La TLS con autenticación de backend limita la cadena de certificados que se recibe del backend a no más de 16 KB y 10 certificados.

  • Los certificados raíz que se usan para la validación no pueden contener más de 10 restricciones de nombres.

  • La cantidad máxima de nombres alternativos de entidad permitidos en el campo tlsSettings.subjectAltNames[] es 5.

¿Qué sigue?