Compartir vía

Acerca del cifrado TLS con Azure Front Door

  • Artículo

Importante

La compatibilidad con TLS 1.0 y 1.1 se interrumpirá el 1 de marzo de 2025.

Seguridad de la capa de transporte (TLS), antes conocido como Capa de sockets seguros (SSL), es la tecnología de seguridad estándar para establecer un vínculo cifrado entre un servidor web y un cliente, como un explorador web. Este vínculo garantiza que todos los datos transmitidos entre el servidor y el cliente permanezcan privados y encriptados.

Para cumplir los requisitos de seguridad o cumplimiento, Azure Front Door admite el cifrado TLS de un extremo a otro. La descarga de TLS/SSL de Front Door finaliza la conexión TLS, descifra el tráfico en Azure Front Door y vuelve a cifrar el tráfico antes de reenviarlo al origen. Cuando las conexiones al origen usen la dirección IP pública del origen se recomienda configurar HTTPS como protocolo de reenvío en Azure Front Door. Mediante el uso de HTTPS como protocolo de reenvío es posible aplicar el cifrado TLS de un extremo a otro para todo el procesamiento de la solicitud del cliente al origen. También se admite la descarga TLS/SSL si implementa un origen con Azure Front Door Premium mediante la característica Private Link.

En este artículo se explica cómo funciona Azure Front Door con conexiones TLS. Para obtener más información sobre cómo usar certificados TLS con sus propios dominios personalizados, consulte HTTPS para dominios personalizados. Para aprender a configurar un certificado TLS en su propio dominio personalizado, consulte Configuración de un dominio personalizado en Azure Front Door mediante Azure Portal.

Cifrado TLS de un extremo a otro

TLS de un extremo a otro permite proteger los datos confidenciales mientras están en tránsito al origen, al tiempo que se beneficia de las características de Azure Front Door, como el equilibrio de carga global y el almacenamiento en caché. Algunas de las características también incluyen el enrutamiento basado en URL, la división TCP, el almacenamiento en caché en la ubicación perimetral más cercana a los clientes y la personalización de solicitudes HTTP en el perímetro.

Azure Front Door descarga las sesiones TLS en el perímetro y descifra las solicitudes de cliente. A continuación, aplica las reglas de enrutamiento configuradas para enrutar las solicitudes al origen adecuado en el grupo de origen. Entonces, Azure Front Door inicia una nueva conexión TLS al origen y vuelve a cifrar todos los datos mediante el certificado del origen antes de transmitir la solicitud al origen. Cualquier respuesta del origen se cifra a través del mismo proceso de vuelta al usuario final. Puede configurar su instancia de Azure Front Door para usar HTTPS como protocolo de reenvío para habilitar TLS de un extremo a otro.

Versiones de TLS admitidas

Azure Front Door es compatible actualmente con cuatro versiones del protocolo TLS: TLS versiones 1.0, 1.1, 1.2 y 1.3. Todos los perfiles de Azure Front Door creados después de septiembre de 2019 utilizan TLS 1.2 como mínimo de manera predeterminada con TLS 1.3 habilitado, pero TLS 1.0 y TLS 1.1 siguen siendo compatibles con versiones anteriores. La compatibilidad con TLS 1.0 y 1.1 se interrumpirá el 1 de marzo de 2025.

Aunque Azure Front Door admite TLS 1.2, que introdujo la autenticación mutua o cliente en RFC 5246, actualmente, Azure Front Door aún no admite la autenticación mutua o cliente (mTLS).

Puede configurar la versión de TLS mínima en Azure Front Door en la configuración HTTPS del dominio personalizado desde Azure Portal o la API REST de Azure. Actualmente, puede elegir entre 1.0 y 1.2. Por lo tanto, si se especifica TLS 1.2 como versión mínima, se controla la versión mínima aceptable de TLS que Azure Front Door aceptará de un cliente. Para la versión mínima de TLS 1.2, la negociación intentará establecer TLS 1.3 y, después, TLS 1.2, mientras que para la versión mínima de TLS 1.0 se intentarán las cuatro versiones. Cuando Azure Front Door inicia el tráfico TLS hacia el origen, intentará negociar la mejor versión de TLS que el origen pueda aceptar de forma fiable y coherente. Las versiones de TLS admitidas para las conexiones de origen son TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.3. La compatibilidad con TLS 1.0 y 1.1 se interrumpirá el 1 de marzo de 2025.

Nota:

  • Los clientes con TLS 1.3 habilitados son necesarios para admitir una de las curvas EC compatibles con SDL de Microsoft, incluidas Secp384r1, Secp256r1 y Secp521, con el fin de realizar correctamente solicitudes con Azure Front Door mediante TLS 1.3.
  • Se recomienda que los clientes usen una de estas curvas como su curva preferida durante las solicitudes para evitar un aumento de la latencia del protocolo de enlace TLS, lo que podría ocurrir como consecuencia de los varios recorridos de ida y vuelta para negociar la curva EC admitida.

Certificados admitidos

Al crear el certificado TLS/SSL, tiene que crear una cadena de certificados completa con una entidad de certificación (CA) permitida que forme parte de la lista de CA de confianza de Microsoft. Si usa una CA no permitida, la solicitud se rechazará.

No se permiten certificados de entidades de certificación internas ni certificados autofirmados.

Asociación del Protocolo de estado de certificados en línea (OCSP)

De forma predeterminada, la asociación OCSP es compatible en Azure Front Door y no se requiere ninguna configuración.

Conexión TLS de origen (Azure Front Door a origen)

En el caso de las conexiones HTTPS, Azure Front Door espera que el origen presente el certificado de una entidad de certificación válida con un nombre de firmante que coincida con el nombre de host del origen. Por ejemplo, si su nombre de host de origen está establecido en myapp-centralus.contosonews.net y el certificado que presenta su origen durante el protocolo de enlace TLS no tiene myapp-centralus.contosonews.net o *.contosonews.net en el nombre del sujeto, Azure Front Door rechazará la conexión y el cliente verá un error.

Nota

El certificado debe tener una cadena de certificados completa con certificados hoja e intermedios. La entidad de certificación raíz debe formar parte de la lista de CA de confianza de Microsoft. Si se presenta un certificado sin una cadena completa, no se garantiza que las solicitudes que involucran ese certificado funcionen según lo previsto.

En determinados casos de uso, como para las pruebas, como solución alternativa para resolver errores de conexión HTTPS, es posible deshabilitar la comprobación del nombre del sujeto del certificado para Azure Front Door. Tenga en cuenta que el origen todavía necesita presentar un certificado con una cadena de confianza válida, pero no tiene que coincidir con el nombre de host de origen.

En Azure Front Door Standard y Premium es posible configurar un origen para deshabilitar la comprobación del nombre del firmante del certificado.

En Azure Front Door (clásico) es posible deshabilitar la comprobación del nombre del firmante del certificado cambiando la configuración de Azure Front Door en Azure Portal. También se puede configurar la comprobación mediante la configuración del grupo de back-end en las API de Azure Front Door.

Nota

Desde el punto de vista de la seguridad, Microsoft no recomienda deshabilitar la comprobación del nombre del firmante del certificado.

Conexión de TLS de front-end (cliente a Azure Front Door)

Para habilitar el protocolo HTTPS para distribuir de forma segura el contenido en un dominio personalizado de Azure Front Door, puede optar por usar un certificado administrado por Azure Front Door o usar su propio certificado.

Para obtener más información, consulte HTTPS para dominios personalizados.

El certificado administrado de Azure Front Door proporciona un certificado TLS/SSL estándar a través de DigiCert y se almacena en la instancia de Key Vault de Azure Front Door.

Si decide usar su propio certificado, puede incorporar un certificado de una entidad de certificación compatible que puede ser un TLS estándar, un certificado de validación extendido o incluso un certificado comodín. No se admiten certificados autofirmados. Aprenda a habilitar HTTPS para un dominio personalizado.

Rotación automática de certificados

En el caso de la opción de certificado administrado de Azure Front Door, este administra y rota automáticamente los certificados en los 90 días posteriores al tiempo de expiración. En el caso de la opción de certificado administrado estándar o premium de Azure Front Door, este administra y rota automáticamente los certificados en los 45 días posteriores al tiempo de expiración. Si usa un certificado administrado de Azure Front Door y observa que la fecha de expiración del certificado es inferior a 60 días, o 30 en el caso de la SKU estándar o premium, cree una incidencia de soporte técnico.

Para su propio certificado TLS/SSL personalizado:

  1. Establezca la versión del secreto en "Más reciente" para que el certificado se rote automáticamente a la versión más reciente cuando haya disponible una versión más reciente del certificado en el almacén de claves. En el caso de los certificados personalizados, el certificado rota automáticamente en un plazo de 3 a 4 días con una versión más reciente, independientemente del tiempo de expiración del certificado.

  2. Si se selecciona una versión específica, no se admite la rotación automática. Tendrá que volver a seleccionar la nueva versión manualmente para rotar el certificado. La nueva versión del certificado o el secreto tarda hasta 24 horas en implementarse.

    Nota:

    Los certificados administrados de Azure Front Door (Estándar y Premium) se giran automáticamente si el registro CNAME del dominio apunta directamente a un punto de conexión de Front Door o indirectamente a un punto de conexión de Traffic Manager. De lo contrario, debe volver a validar la propiedad del dominio para girar los certificados.

    Tendrá que asegurarse de que la entidad de servicio de Front Door siga teniendo acceso al almacén de claves. Consulte cómo conceder acceso al almacén de claves. La operación de implementación de certificados actualizados por parte de Azure Front Door no provocará ningún tiempo de inactividad de producción, siempre que el nombre del sujeto o el nombre alternativo del sujeto (SAN) para el certificado no hayan cambiado.

Conjuntos de cifrado admitidos

Para TLS 1.2/1.3 se admiten los siguientes conjuntos de cifrado:

  • TLS_AES_256_GCM_SHA384 (solo TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (solo TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Nota

Para Windows 10 y versiones posteriores, se recomienda habilitar uno o ambos conjuntos de cifrado ECDHE_GCM para mejorar la seguridad. Windows 8.1, 8 y 7 no son compatibles con estos conjuntos de cifrado ECDHE_GCM. Los conjuntos de cifrado ECDHE_CBC y DHE proporcionan compatibilidad con esos sistemas operativos.

Al usar dominios personalizados con TLS 1.0 y 1.1 habilitados, se admiten los siguientes conjuntos de cifrado:

  • TLS_AES_256_GCM_SHA384 (solo TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (solo TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door no admite la deshabilitación ni la configuración de conjuntos de cifrado específicos para el perfil.

Pasos siguientes