Introducción a la autenticación mutua con Application Gateway

La autenticación mutua o la autenticación de cliente permiten a Application Gateway autenticar las solicitudes de envío del cliente. Normalmente, solo el cliente autentica Application Gateway. La autenticación mutua permite que el cliente y Application Gateway se autentiquen entre sí.

Nota:

Se recomienda usar TLS 1.2 con autenticación mutua, ya que TLS 1.2 será obligatorio en el futuro.

Autenticación mutua

Application Gateway admite la autenticación mutua basada en certificados. Puede cargar certificados de entidad de certificación de cliente de confianza en Application Gateway y la puerta de enlace usa esos certificados para autenticar a los clientes que envían solicitudes. Con el aumento de los casos de uso de IoT y el aumento de los requisitos de seguridad en los sectores, la autenticación mutua proporciona una manera de administrar y controlar qué clientes pueden comunicarse con application Gateway.

Application Gateway proporciona las dos opciones siguientes para validar los certificados de cliente:

Modo de paso a través de TLS mutuo

En el modo de acceso directo de TLS mutua (mTLS), Application Gateway solicita un certificado de cliente durante el protocolo de enlace TLS, pero no finaliza la conexión si falta el certificado o no es válido. La conexión al back-end continúa independientemente de la presencia o validez del certificado. Si se proporciona un certificado, Application Gateway puede reenviarlo al back-end si es necesario por la aplicación. El servicio back-end es responsable de validar el certificado de cliente.

Ventajas del modo de paso a través de mTLS

El modo de paso a través de mTLS proporciona las siguientes ventajas:

  • Configuración simplificada de la puerta de enlace: no se requiere cargar certificados de entidad de certificación en el nivel de la puerta de enlace.
  • Autenticación flexible: admite escenarios de tráfico mixto en los que algunos clientes usan certificados y otros usan la autenticación basada en tokens.
  • Cumplimiento de directivas de back-end: permite que la aplicación back-end implemente directivas y lógicas de validación de certificados personalizadas.
  • Sobrecarga de puerta de enlace reducida: descarga la validación del certificado en el back-end, lo que reduce el procesamiento en la puerta de enlace.
  • Compatibilidad con la migración gradual: habilita el lanzamiento por fases de mTLS sin interrumpir los patrones de tráfico existentes.

Para reenviar certificados de cliente al back-end, configure las variables de servidor. Para obtener más información, consulte Variables de servidor.

Configuración del modo de paso a través de mTLS

Puede configurar el modo de paso a través de mTLS mediante el portal de Azure o las plantillas de ARM.

Para configurar el modo de paso a través de mTLS en el portal de Azure:

  1. Vaya a su recurso de Application Gateway.

  2. En Configuración, seleccione Perfiles SSL.

  3. Seleccione + Agregar para crear un nuevo perfil SSL.

  4. Escriba un nombre para el perfil SSL.

  5. En la pestaña Autenticación de cliente , seleccione Paso a través.

    En el modo de acceso directo, el certificado de cliente es opcional. El servidor back-end es responsable de la autenticación de cliente.

    Screenshot que muestra el cuadro de diálogo Crear perfil SSL en el portal de Azure con Passthrough seleccionado para el método de autenticación de cliente.

  6. Configure las opciones de directiva SSL según sea necesario.

  7. Seleccione Agregar para crear el perfil SSL.

  8. Asocie el perfil SSL al agente de escucha HTTPS.

Nota:

La compatibilidad de PowerShell y la CLI con la configuración de paso a través no está disponible actualmente.

Modo estricto de TLS mutuo

En el modo estricto de TLS mutuo, Application Gateway aplica la autenticación de certificados de cliente durante el protocolo de enlace TLS al requerir un certificado de cliente válido. Para habilitar el modo estricto, cargue un certificado de Autoridad de Certificación (CA) de cliente de confianza como parte del perfil de SSL, que contenga una CA raíz y, opcionalmente, CAs intermedias. Asocie este perfil SSL a una escucha para implementar la autenticación mutua.

Configurar el modo estricto de TLS mutuo

Para configurar el modo estricto de autenticación mutua, cargue un certificado de autoridad de certificación (CA) de cliente de confianza como parte de la autenticación de cliente de un perfil SSL. A continuación, asocie el perfil SSL a un agente de escucha para completar la configuración. El certificado de cliente que cargue siempre debe incluir un certificado de entidad de certificación raíz. Puede cargar una cadena de certificados, pero esta debe incluir un certificado de Autoridad de Certificación Raíz, además de cualquier certificado de Autoridad de Certificación intermedio. El tamaño máximo de cada archivo cargado debe ser de 25 KB o menos.

Por ejemplo, si el certificado de cliente contiene un certificado de entidad de certificación raíz, varios certificados de CA intermedios y un certificado hoja, cargue el certificado de entidad de certificación raíz y todos los certificados de CA intermedios en Application Gateway en un archivo. Para obtener más información sobre cómo extraer un certificado CA de cliente de confianza, consulte Extracción de certificados CA de cliente de confianza.

Si vas a cargar una cadena de certificados con autoridad de certificación raíz y autoridad de certificación intermedia, súbela como un archivo PEM o CER al servidor de puerta de enlace.

Importante

Cargue toda la cadena de certificados de la entidad certificadora de cliente de confianza en el Application Gateway cuando utilice la autenticación mutua.

Cada perfil SSL puede admitir hasta 100 cadenas de certificados de entidad de certificación de cliente de confianza. Una sola instancia de Application Gateway puede admitir un total de 200 cadenas de certificados de entidad de certificación de cliente de confianza.

Nota:

  • La autenticación mutua solo está disponible en SKU de Standard_v2 y WAF_v2.
  • La configuración de la autenticación mutua para los agentes de escucha de protocolo TLS está disponible actualmente a través de la API REST, PowerShell y la CLI.

Certificados admitidos para la autenticación mutua en modo TLS estricto

Application Gateway admite certificados emitidos por entidades de certificación públicas y privadas establecidas.

  • Certificados de autoridad de certificación emitidos por entidades de certificación conocidas: los certificados intermedios y raíz se encuentran normalmente en almacenes de certificados de confianza y permiten establecer conexiones seguras con poca o ninguna configuración adicional en el dispositivo.
  • Certificados emitidos por las autoridades certificadoras establecidas por la organización: estos certificados normalmente se emiten de forma privada dentro de la organización y no son de confianza para otras entidades. Importe certificados intermedios y raíz en almacenes de certificados de confianza para que los clientes establezcan la confianza en la cadena.

Nota:

Al emitir certificados de cliente de entidades de certificación bien establecidas, considere la posibilidad de trabajar con la entidad de certificación para ver si se puede emitir un certificado intermedio para su organización. Este enfoque impide la autenticación involuntaria de certificados de cliente entre organizaciones.

Validación de autenticación de cliente para el modo estricto de TLS mutuo

Comprobar el DN de certificado de cliente

Puede comprobar el emisor inmediato del certificado de cliente y permitir solo que Application Gateway confíe en ese emisor. Esta opción está desactivada de forma predeterminada, pero puede habilitarla a través del portal, PowerShell o CLI de Azure.

Si habilita Application Gateway para comprobar el emisor inmediato del certificado de cliente, los escenarios siguientes describen cómo se extrae el DN del emisor de certificados de cliente de los certificados cargados:

  • Escenario 1: La cadena de certificados incluye el certificado raíz, el certificado intermedio y el certificado hoja.
    • El nombre del firmante del certificado intermedio se extrae como DN del emisor de certificados de cliente.
  • Escenario 2: La cadena de certificados incluye el certificado raíz, el certificado intermedio1, el certificado intermedio2 y el certificado hoja.
    • El nombre del sujeto del certificado intermedio2 se extrae como DN del emisor del certificado de cliente.
  • Escenario 3: La cadena de certificados incluye el certificado raíz y el certificado hoja.
    • El nombre del sujeto del certificado raíz se extrae como DN del emisor del certificado de cliente.
  • Escenario 4: varias cadenas de certificados de la misma longitud en el mismo archivo. La cadena 1 incluye el certificado raíz, el certificado intermedio1 y el certificado hoja. La cadena 2 incluye el certificado raíz, el certificado intermedio 2 y el certificado hoja.
    • El nombre del sujeto del certificado intermedio1 se extrae como el DN del emisor del certificado de cliente.
  • Escenario 5: varias cadenas de certificados de diferentes longitudes en el mismo archivo. La cadena 1 incluye el certificado raíz, el certificado intermedio1 y el certificado hoja. La cadena 2 incluye el certificado raíz, el certificado intermedio2, el certificado intermedio3 y el certificado hoja.
    • El nombre del sujeto del certificado intermedio3 se extrae como nombre del DN del emisor del certificado de cliente.

Importante

Se recomienda cargar solo una cadena de certificados por archivo. Esta recomendación es especialmente importante si habilita la opción comprobar el DN del certificado de cliente. La carga de varias cadenas de certificados en un archivo da como resultado el escenario cuatro o cinco, lo que puede provocar problemas más adelante cuando el certificado de cliente presentado no coincide con el DN del emisor de certificados de cliente que Application Gateway extrajo de las cadenas.

Para obtener más información sobre cómo extraer cadenas de certificados CA de cliente de confianza, consulte Extracción de cadenas de certificados CA de cliente de confianza.

Variables de servidor

Con la autenticación TLS mutua, puede usar variables de servidor adicionales para pasar información sobre el certificado de cliente a los servidores back-end detrás de Application Gateway. Para obtener más información sobre qué variables de servidor están disponibles y cómo usarlas, consulte Variables de servidor.

Revocación de certificados

Cuando un cliente inicia una conexión a una instancia de Application Gateway configurada con autenticación TLS mutua, se puede validar la cadena de certificados y el nombre distintivo del emisor. Además, el estado de revocación del certificado de cliente se puede comprobar con OCSP (Protocolo de estado de certificado en línea). Durante la validación, el certificado presentado por el cliente se busca a través del respondedor OCSP definido en su extensión Authority Information Access (AIA). Si se ha revocado el certificado de cliente, Application Gateway responde al cliente con un código de estado HTTP 400 y un motivo. Si el certificado es válido, Application Gateway sigue procesando la solicitud y reenviada al grupo de back-end definido.

Puede habilitar la revocación de certificados de cliente mediante la API REST, la plantilla de ARM, los Bicep, la CLI o PowerShell.

Para configurar la comprobación de revocación de cliente en una instancia de Application Gateway existente mediante Azure PowerShell, use los siguientes comandos:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Para obtener una lista de todas las referencias de Azure PowerShell para la configuración de autenticación de cliente en Application Gateway, consulte los siguientes artículos:

Para comprobar que el estado de revocación de OCSP se evaluó para la solicitud de cliente, los registros de acceso contienen una propiedad denominada sslClientVerify que muestra el estado de la respuesta OCSP.

Es fundamental que el respondedor OCSP tenga una alta disponibilidad y que la conectividad de red entre Application Gateway y el respondedor sea posible. Si Application Gateway no puede resolver el nombre de dominio completo (FQDN) del respondedor definido, o si la conectividad de red está bloqueada para o desde el respondedor, se produce un error en el estado de revocación de certificados y Application Gateway devuelve una respuesta HTTP 400 al cliente solicitante.

Nota:

Las comprobaciones de OCSP se validan a través de la caché local en función del nextUpdate tiempo definido por una respuesta OCSP anterior. Si la memoria caché OCSP no se ha rellenado desde una solicitud anterior, es posible que se produzca un error en la primera respuesta. Tras reintentar el cliente, la respuesta debe encontrarse en la memoria caché y la solicitud se procesa según lo previsto.

Notas

  • No se admite la comprobación de revocación a través de CRL.
  • La verificación de revocación del cliente se introdujo en la versión de la API 2022-05-01.

Contenido relacionado

Después de obtener información sobre la autenticación mutua, vaya a Configuración de Application Gateway con autenticación mutua en PowerShell para crear una instancia de Application Gateway que use la autenticación mutua.

  • Last updated on