Información general sobre TLS autenticado por backend y mTLS de backend

Cuando un balanceador de carga se conecta a backends que se encuentran en Google Cloud, el balanceador de carga acepta cualquier certificado que presenten tus backends. En estos casos, el balanceador de carga no realiza ninguna validación de certificados.

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

En el siguiente diagrama se muestra la diferencia entre el mTLS de frontend y el de backend, centrándose en el rol del balanceador de carga en cada caso. En mTLS de frontend, el balanceador de carga actúa como servidor y verifica la identidad del cliente. En la autenticación mTLS de backend, el balanceador de carga actúa como cliente y demuestra su identidad al backend.

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

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 ofrece una descripción general de TLS autenticado por backend y de mTLS de backend. Para obtener más información sobre mTLS de frontend, consulta el resumen de TLS mutuo.

Se pueden configurar TLS autenticado de backend y mTLS de backend en el recurso de servicio de backend de los siguientes balanceadores de carga:

• Balanceadores de carga de aplicación externos globales
• Balanceadores de carga de aplicación externos regionales
• Balanceadores de carga de aplicación internos regionales

Funciones

La autenticación mutua de TLS (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 de certificación (AC). TLS autenticado de backend y mTLS de backend añaden las siguientes funciones a los balanceadores de carga de aplicaciones:

• El balanceador de carga puede validar los certificados presentados por los back-ends con tus propias anclas de confianza. Puedes subir varios anclajes de confianza para habilitar una migración fluida de una infraestructura de clave pública anterior a una nueva sin tiempo de inactividad.

• El balanceador de carga puede validar los certificados TLS de los back-ends con respecto a las raíces de confianza públicas (infraestructura de clave pública web).

• Puede configurar certificados intermedios además de sus anclas de confianza para ayudar a crear la ruta de validación de certificados de backend. El uso de certificados intermedios significa que tus servidores backend no tienen que proporcionar la cadena de certificados completa.

• Puedes configurar un nombre de host de indicación de nombre de servidor (SNI) de TLS para tu servicio de backend. Durante la negociación de TLS, el balanceador de carga incluye este nombre de host SNI en el mensaje ClientHello que envía al backend. A continuación, el backend responde con su certificado TLS y el balanceador de carga 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 SAN configurados para el servicio de backend.

• Puedes configurar el servicio de backend de tu balanceador de carga para que use mTLS de forma que el balanceador de carga pueda demostrar su identidad a los backends. Esta autenticación se lleva a cabo mediante un certificado de cliente (balanceador de carga) que el balanceador de carga presenta al backend.

Requisitos de los certificados

Al configurar certificados para TLS autenticado de backend y mTLS de backend, 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 cifrado con hash criptográfica más segura. No se admiten algoritmos de cifrado hash como MD4, MD5 y SHA-1.

• Los certificados de servidor hoja proporcionados por el backend deben cumplir los siguientes requisitos:

  • La extensión basicConstraints no debe contener CA=true.
  • La extensión Uso mejorado de claves debe contener serverAuth.
  • La extensión Uso mejorado de claves no debe contener los campos codeSigning, timeStamping ni OCSPSigning.
  • El certificado no debe haber caducado.

• En el caso de los certificados de cliente hoja (balanceador de carga) que se usan en mTLS de backend, el certificado debe ser un recurso de certificado de Certificate Manager. El ámbito de este certificado debe ser client-auth, lo que indica que se usa como certificado de cliente en mTLS de backend.

  • La extensión basicConstraints 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.

• Para autenticar los certificados de servidor que tu backend presenta al balanceador de carga, los certificados raíz e intermedios que se encuentran en la configuración de confianza deben cumplir los siguientes requisitos:

  • La extensión restricciones básicas debe contener CA=true.
  • La extensión key usage debe tener el valor keyCertSign.
  • La extensión Uso mejorado de claves debe contener el campo serverAuth.
  • El certificado no debe haber caducado.

Componentes clave de TLS autenticado de backend y mTLS de backend

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

Para configurar TLS autenticado por 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 dirígelo al recurso de configuración de autenticación de backend.

Para configurar 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 backend de un balanceador de carga de aplicaciones, que habilitan TLS autenticado por backend y mTLS de backend.

Componentes de TLS autenticado por backend y mTLS de backend (haz clic para ampliar).

La información que se proporciona a continuación ofrece una descripción general de los diferentes componentes que se usan para configurar TLS autenticado de backend y mTLS de backend.

Configuración de confianza

Para autenticar los certificados de servidor que tu backend presenta al balanceador de carga, este debe configurarse con certificados X.509 que establezcan una cadena de confianza con el emisor del certificado del backend. Para configurar la confianza, debes usar un TrustConfig recurso, que expresa toda la configuración de confianza y contiene un único almacén de confianza.

Un almacén de confianza encapsula un ancla de confianza (certificado raíz) y, opcionalmente, uno o varios certificados intermedios. Una 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 un ancla de confianza del almacén de confianza.

Un certificado intermedio es un certificado que forma parte de una cadena de confianza que lleva a una ancla de confianza en el almacén de confianza. Se usa junto con cualquier AC intermedia adicional incluida en el certificado de hoja para crear la cadena de confianza durante el proceso de validación. Crear un certificado intermedio es opcional.

Si necesitas usar un certificado autofirmado, caducado, que no esté encadenado a una raíz de confianza especificada o que no haya superado la validación, puedes añadirlo a una lista de permitidos en la configuración de confianza. También puedes crear un certificado autofirmado que se pueda añadir a una lista de permitidos.

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

La configuración de autenticación de backend (recurso BackendAuthenticationConfig) se adjunta al servicio de backend del balanceador de carga y realiza las siguientes funciones:

• Habilita TLS autenticado de backend (autenticación de backend) mediante la configuración de confianza y las raíces de confianza públicas.
• Además, habilita mTLS de backend mediante el certificado de cliente.

Para habilitar TLS autenticado por 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): la configuración de confianza adjunta que se usa para validar el certificado del servidor proporcionado por el backend. No es necesaria la configuración de confianza cuando la configuración de autenticación del backend usa las raíces de confianza públicas para validar el certificado del servidor.

• Raíces de confianza públicas (wellKnownRoots): indica si el balanceador de carga confía en los certificados de servidor backend que han sido emitidos por ACs públicas, además de los certificados de confianza configurados. Para obtener más información, consulta Usar raíces de confianza públicas.

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

Nota: No se puede enviar un certificado de cliente al backend sin configurar primero TLS autenticado por backend. Esto se debe a que el balanceador de carga no puede presentar su certificado al backend sin validar primero el certificado que ha presentado el backend.

Servicio de backend

En el servicio 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 SNI (sni)
• SANs aceptados (subjectAltNames)

Nota: Configurar el nombre de host SNI y los SANs aceptados en el servicio de backend para verificar el certificado de backend es opcional. Sin embargo, no puedes validar el certificado de backend sin configurar el recurso de configuración de autenticación de backend en el servicio de backend. En otras palabras, el certificado de backend debe validarse mediante una cadena de certificados de confianza, que se expresa mediante una configuración de confianza.

Los campos SNI (sni) y SAN (subjectAltNames) del atributo tlsSettings controlan cómo valida el balanceador de carga el certificado del backend en función de los valores SAN del certificado. Estos campos influyen en el proceso de validación independientemente de si se ha configurado la autenticación TLS de backend.

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

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

De forma predeterminada, el balanceador de carga comprueba que el certificado TLS del backend incluya un SAN que coincida con el nombre de host de SNI. Sin embargo, si se configuran SANs en el servicio de backend (tlsSettings.subjectAltNames), el balanceador de carga hará lo siguiente:

• Ignora el nombre de host SNI para la verificación SAN.
• Verifica que el certificado TLS del backend incluya una SAN que coincida con una de las SANs aceptadas (subjectAltNames) configuradas en el servicio del backend.

Certificado de cliente

Además de la autenticación TLS de backend (autenticación de backend), puedes configurar el servicio de backend de un balanceador de carga para que use mTLS, de forma que el balanceador de carga pueda demostrar su identidad al backend. Esta autenticación usa un certificado de cliente (balanceador de carga) que el balanceador de carga 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 carga) y su clave privada.
• Adjunta el certificado de cliente al recurso de configuración de autenticación de backend.

La autenticación mTLS de backend también es compatible con las identidades de carga de trabajo gestionadas de Compute Engine cuando configuras certificados gestionados a través de Gestor de certificados. No se admiten los certificados gestionados de PKI pública y todos los certificados de cliente deben tener un client-auth ámbito y cumplir 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 carga, este devuelve un código de estado HTTP 502 para las solicitudes que esté proxyizando y registra un estado genérico en Cloud Logging.

Configurar TLS autenticado de backend y mTLS de backend en el balanceador de carga

Puedes configurar TLS autenticado de backend y mTLS de backend en el balanceador de carga mediante una PKI privada o raíces de confianza públicas.

Usar una PKI privada

A continuación, se muestra un resumen de los pasos clave que debes seguir para configurar TLS autenticado de backend y mTLS de backend en tu balanceador de carga mediante certificados emitidos por tu infraestructura de clave pública privada. La infraestructura de clave pública privada tiene la ventaja de estar totalmente bajo tu control y aislada de los sistemas de infraestructura de clave pública de Internet.

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 carga) 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 quieres configurar 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. Asocia el recurso de configuración de autenticación de backend al servicio de backend del balanceador de carga.

Ten en cuenta lo siguiente:

• No es posible enviar un certificado de cliente al backend sin configurar primero TLS autenticado por el backend.

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

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

• Configurar TLS autenticado de backend

• Configurar mTLS de backend

Usar raíces de confianza públicas

Además de usar certificados emitidos por tu infraestructura de clave pública privada para habilitar TLS autenticado en el backend, también puedes usar raíces públicas de confianza para validar el certificado del backend.

Para usar raíces de confianza públicas, no es necesario crear una configuración de confianza ni adjuntarla al recurso de configuración de autenticación de backend. En su lugar, debe asignar PUBLIC_ROOTS como valor al campo wellKnownRoots del recurso de configuración de autenticación del backend. Dicho esto, también puedes crear una configuración de confianza que incluya explícitamente las raíces de tus certificados emitidos públicamente, además de los certificados de confianza de la configuración de confianza.

El ajuste PUBLIC_ROOTS usa un conjunto de ACs raíz, similar al conjunto de ACs raíz de confianza de los navegadores, que gestiona Google y que puede cambiar con el tiempo. Esto supone un riesgo de que tus certificados de backend dejen de ser válidos cuando cambien estas raíces. Si necesitas validar certificados emitidos públicamente, te recomendamos que elijas una AC fiable y consolidada que utilice la firma cruzada intermedia para emitir tus certificados de backend. De esta forma, se reduce el riesgo de que caduque o se revoque un certificado raíz.

Pasos para validar el certificado del servidor

Al validar el certificado de servidor durante la autenticación TLS autenticada por backend o la autenticación de backend, el balanceador de carga hace lo siguiente:

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

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

2. Verifica la cadena de confianza.

   Si la configuración de confianza incluye al menos una ancla de confianza o tiene el atributo wellKnownRoots definido como PUBLIC_ROOTS, el balanceador de carga intenta verificar una cadena de confianza entre el certificado de servidor y la ancla de confianza configurada. Las comprobaciones de verificación incluyen lo siguiente:

   • El certificado de servidor del backend, los certificados intermedios (si se proporcionan) y el certificado raíz configurado cumplen los requisitos de los certificados.
   • En 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 asegurar que la identidad (sujeto) del certificado principal sea la misma que la identidad que aparece como emisor en el certificado secundario.
   • En todos los certificados de la cadena de confianza, 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: El certificado secundario se ha 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.
   Nota: Los certificados de cliente autofirmados no forman una cadena de confianza válida y siempre se rechazan.

3. Establece una conexión con el backend.

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

   Sin embargo, si la validación del certificado falla, el balanceador de carga 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. Si se produce un error de validación de certificado, las solicitudes entrantes posteriores harán que el balanceador de carga reinicie la conexión de backend.

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

Gestión de errores y registro

Los balanceadores de carga de aplicaciones proporcionan funciones de registro detalladas que te permiten monitorizar la validación de los certificados de servidor, 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.

Si falla la validación del certificado del servidor, 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 del servidor	Error registrado
La cadena de certificados del servidor es demasiado larga (más de 10 certificados intermedios incluidos en el certificado del servidor).	server_cert_chain_exceeded_limit
Un servidor 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.	server_cert_invalid_rsa_key_size
Un servidor 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.	server_cert_unsupported_elliptic_curve_key
Un servidor o un certificado intermedio usa un algoritmo que no es RSA ni ECDSA. No se realiza ninguna validación.	server_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.	server_cert_pki_too_large
Un certificado intermedio proporcionado para la validación tenía más de 10 restricciones de nombre.	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 ha superado el tiempo límite al intentar validar la cadena de certificados.	server_cert_validation_timed_out
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 servidor. El número máximo de iteraciones es 100 (certificados examinados para validar la cadena de certificados del servidor).	server_cert_validation_search_limit_exceeded
Has configurado mTLS sin configurar un recurso TrustConfig.	server_cert_validation_not_performed
El servidor no ha proporcionado el certificado solicitado durante la negociación.	server_cert_not_provided
No se ha podido 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
Error interno al validar la cadena de certificados.	server_cert_validation_internal_error
No se ha encontrado ningún TrustConfig que coincida.	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

• No se admiten TLS autenticado de backend ni mTLS de backend en los balanceadores de carga de aplicaciones clásicos.

• No se admiten TLS autenticado por backend ni mTLS de backend para los siguientes tipos de backend:

  • Backends de NEGs de Internet globales

  • Backends de App Engine

• Las comprobaciones de estado que usan los backends no implementan la autenticación TLS ni las funciones de mTLS. Debes configurar los backends con endpoints de comprobación del estado que puedan responder a solicitudes HTTP o HTTPS.

• El balanceador de carga no transfiere el nombre de host SNI del cliente desde la conexión TLS de frontend al conectarse a un backend. Sin embargo, los back-ends pueden acceder al nombre de host SNI del cliente mediante un encabezado de solicitud personalizado.

• En el caso de mTLS de backend, las claves de certificado de cliente solo pueden ser de los siguientes tipos:

  • Las claves RSA pueden tener entre 2048 y 4096 bits.
  • Las claves ECDSA pueden usar las curvas P-256 o P-384.

• TLS autenticado por backend no admite comprobaciones de revocación de certificados.

Cuotas y límites

• Un único 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 se pueden compartir más de tres certificados intermedios con la misma información de Subject y Subject Public Key.

• La profundidad máxima de una cadena de certificados es de 10 certificados, incluidos los certificados raíz y hoja. El número máximo de certificados intermedios que se pueden evaluar al intentar crear la cadena de confianza es 100.

• TLS autenticado por backend limita la cadena de certificados recibida del backend a un máximo 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 nombre.

• El número máximo de nombres alternativos de asunto permitidos en el campo tlsSettings.subjectAltNames[] es 5.

Siguientes pasos

• Configurar TLS autenticado de backend con certificados autogestionados