Compartir vía

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

  • Artículo

La autenticación mutua, o autenticación de cliente, permite que Application Gateway autentique las solicitudes de envío de clientes. Normalmente, es solo el cliente el que se autentica en Application Gateway; la autenticación mutua permite que tanto el cliente como Application Gateway se autentiquen entre sí.

Nota

Se recomienda usar TLS 1.2 con la autenticación mutua, ya que esta versión será obligatoria en el futuro.

Autenticación mutua

Application Gateway admite la autenticación mutua basada en certificados, en la que puede cargar certificados de entidades de certificación de clientes de confianza en Application Gateway para que la puerta de enlace use esos certificados a fin de autenticar al cliente que envía una solicitud a la puerta de enlace. Con el aumento de casos de uso de IoT y unos mayores requisitos de seguridad en los diversos sectores, la autenticación mutua proporciona una manera de administrar y controlar qué clientes pueden comunicarse con su instancia de Application Gateway.

Para configurar la autenticación mutua, es necesario cargar un certificado de entidad de certificación de cliente de confianza como parte de la autenticación del cliente de un perfil de SSL. El perfil de SSL deberá asociarse a un cliente de escucha para completar la configuración de la autenticación mutua. Siempre debe haber un certificado de entidad de certificación raíz en el certificado de cliente que cargue. También puede cargar una cadena de certificados, pero la cadena debe incluir un certificado de una entidad de certificación (CA) raíz, además de todos los certificados de CA intermedios que desee. 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 CA raíz, varios certificados de CA intermedios y un certificado de hoja, asegúrese de que el certificado de CA raíz y todos los certificados de CA intermedios se cargan en Application Gateway en un archivo. Para más información sobre cómo extraer un certificado de entidad de certificación de cliente de confianza, consulte Extracción de certificados de entidad de certificación de cliente de confianza.

Si va a cargar una cadena de certificados con CA raíz y certificados de CA intermedios, la cadena de certificados se debe cargar como un archivo PEM o CER en la puerta de enlace.

Importante

Asegúrese de cargar toda la cadena de certificados de la CA de cliente de confianza en Application Gateway al utilizar 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 las SKU Standard_v2 y WAF_v2.
  • La configuración de la autenticación mutua para los clientes de escucha del protocolo TLS (versión preliminar) está disponible actualmente mediante la API REST, PowerShell y la CLI. Próximamente se agregará la compatibilidad con Azure Portal.

Certificados admitidos para la autenticación mutua

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

  • Certificados de entidad de certificación emitidos por autoridades de certificación conocidas: los certificados intermedios y raíz se encuentran normalmente en almacenes de certificados de confianza y habilitan conexiones de confianza con poca o ninguna configuración adicional en el dispositivo.
  • Certificados de entidad de certificación emitidos por autoridades de certificación establecidas por la organización: normalmente, estos certificados se emiten de forma privada a través de su organización y no son de confianza para otras entidades. Los certificados intermedios y raíz deben importarse en almacenes de certificados de confianza para que los clientes generen confianza en la cadena.

Nota

Al emitir certificados de cliente por 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 a fin de evitar la autenticación involuntaria de certificados de cliente entre organizaciones.

Validación de la autenticación de cliente adicional

Comprobar el DN de certificado de cliente

Tiene la opción de comprobar el emisor inmediato del certificado de cliente y permitir que Application Gateway solo confíe en ese emisor. Esta opción está desactivada de forma predeterminada, pero puede habilitarla mediante Azure Portal, PowerShell o la CLI de Azure.

Si decide habilitar Application Gateway para comprobar el emisor inmediato del certificado de cliente, aquí se indica cómo determinar el DN del emisor del certificado de cliente que se extraerá de los certificados cargados.

  • Escenario 1: la cadena de certificados incluye certificado raíz, certificado intermedio y certificado de hoja.
    • El nombre del firmante del certificado intermedio es lo que Application Gateway extraerá como DN del emisor del certificado de cliente y lo que se comprobará.
  • Escenario 2: la cadena de certificados incluye certificado raíz, certificado intermedio 1, certificado intermedio 2 y certificado de hoja.
    • El nombre del firmante del certificado intermedio 2 es lo que se extraerá como el DN del emisor del certificado de cliente y lo que se comprobará.
  • Escenario 3: la cadena de certificados incluye certificado raíz y certificado de hoja.
    • El nombre del firmante del certificado raíz se extraerá y usará 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: certificado raíz, certificado intermedio 1, certificado de hoja. La cadena 2 incluye: certificado raíz, certificado intermedio 2, certificado de hoja.
    • El nombre del firmante del certificado intermedio 1 se extraerá y usará como DN del emisor del certificado de cliente.
  • Escenario 5: varias cadenas de certificados de diferentes longitudes en el mismo archivo. La cadena 1 incluye: certificado raíz, certificado intermedio 1, certificado de hoja. La cadena 2 incluye: certificado raíz, certificado intermedio 2, certificado intermedio 3 y certificado de hoja.
    • El nombre del firmante del certificado intermedio 3 se extraerá y usará como DN del emisor del certificado de cliente.

Importante

Se recomienda cargar solo una cadena de certificados por cada archivo. Esto es especialmente importante si habilita la comprobación de DN del certificado de cliente. Si carga varias cadenas de certificados en un archivo, terminará en el escenario cuatro o cinco y es posible que surjan problemas más adelante cuando el certificado de cliente presentado no coincida con el DN del emisor del certificado de cliente que Application Gateway extrajo de las cadenas.

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

Variables de servidor

Con la autenticación TLS mutua, existen variables de servidor adicionales que se pueden usar para pasar información sobre el certificado de cliente a los servidores back-end detrás de Application Gateway. Para más información sobre las variables de servidor 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, no solo se pueden validar la cadena de certificados y el nombre distintivo del emisor, sino que 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 buscará mediante el respondedor OCSP definido en su extensión de Acceso a la información de autoridad (AIA). En caso de que se revoque el certificado de cliente, la puerta de enlace de aplicación responderá al cliente con un código de estado HTTP 400 y un motivo. Si el certificado es válido, la puerta de enlace de aplicación seguirá procesando la solicitud, que se reenviará al grupo de back-end definido.

La revocación de certificados de cliente se puede habilitar mediante la API de REST, ARM, Bicep, la CLI o PowerShell.

Para configurar la revocación de clientes en una instancia de Application Gateway existente mediante Azure PowerShell, se puede hacer referencia a 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

Puede encontrar una lista de todas las referencias de Azure PowerShell para la configuración de la autenticación de clientes en Application Gateway aquí:

Para comprobar que el estado de revocación de OCSP se ha evaluado para la solicitud de cliente, los registros de acceso contendrán una propiedad denominada "sslClientVerify" con el estado de la respuesta OCSP.

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

Nota: Las comprobaciones de OCSP se validan a través de la caché local en función de la próxima hora de actualización definida por una respuesta OCSP anterior. Si la memoria caché de OCSP no se ha rellenado a partir de una solicitud anterior, es posible que se produzca un error en la primera respuesta. Tras el reintento del cliente, la respuesta se encontrará en la memoria caché y la solicitud se procesará según lo previsto.

Notas

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

Pasos siguientes

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 mediante la autenticación mutua.