Dominios en Azure Front Door

  • Artículo

Un dominio representa un nombre de dominio personalizado que Azure Front Door usa para recibir el tráfico de la aplicación. Azure Front Door admite la adición de tres tipos de nombres de dominio:

  • Los subdominios son el tipo más común de nombre de dominio personalizado. Un ejemplo de subdominio es myapplication.contoso.com.
  • Los dominios de vértice no contienen un subdominio. Un ejemplo de dominio de vértice es contoso.com. Para más información sobre el uso de dominios de vértice con Azure Front Door, consulte Dominios de vértice.
  • Los dominios con caracteres comodín permiten recibir tráfico para cualquier subdominio. Un ejemplo de dominio con carácter comodín es *.contoso.com. Para más información sobre el uso de dominios con caracteres comodín con Azure Front Door, consulte Dominios con caracteres comodín.

Los dominios se agregan al perfil de Azure Front Door. Puede usar un dominio en varias rutas dentro de un punto de conexión, si usa rutas de acceso diferentes en cada una.

Para aprender a agregar un dominio personalizado al perfil de Azure Front Door, consulte Configurar un dominio personalizado en Azure Front Door mediante el Azure Portal.

Configuración de DNS

Al agregar un dominio al perfil de Azure Front Door, se configuran dos registros en el servidor DNS:

  • Un registro TXT de DNS, necesario para validar la propiedad del nombre de dominio. Para obtener más información sobre los registros TXT de DNS, consulte Validación de dominio.
  • Un registro CNAME de DNS, que controla el flujo de tráfico de Internet a Azure Front Door.

Sugerencia

Puede agregar un nombre de dominio al perfil de Azure Front Door antes de realizar cambios de DNS. Este enfoque puede resultar útil en caso de necesitar que se establezca la configuración de Azure Front Door de forma conjunta, o si tiene un equipo independiente que cambia los registros DNS.

También puede agregar el registro TXT de DNS para validar la propiedad del dominio antes de agregar el registro CNAME para controlar el flujo de tráfico. Este enfoque puede resultar útil para evitar que haya tiempo de inactividad de la migración si ya tiene una aplicación en producción.

Validación del dominio

Todos los dominios agregados a Azure Front Door deben validarse. La validación ayuda a protegerle de una configuración incorrecta accidental y también a proteger a otras personas de la suplantación de dominio. En ciertas situaciones, otro servicio de Azure puede validar previamente los dominios. De lo contrario, debe seguir el proceso de validación de dominio de Azure Front Door para demostrar la propiedad del nombre de dominio.

  • Los dominios validados previamente de Azure son dominios que han sido validados por otro servicio admitido de Azure. Si incorpora y valida un dominio en otro servicio de Azure y configura Azure Front Door más adelante, podría trabajar con un dominio validado previamente. No es necesario validar el dominio mediante Azure Front Door al usar este tipo de dominio.

    Nota

    Actualmente, Azure Front Door solo acepta dominios previamente validados que se han configurado con Aplicaciones web estáticas de Azure.

  • Los dominios no validados por Azure son dominios que no han sido validados por un servicio admitido de Azure. Este tipo de dominio se puede hospedar con cualquier servicio DNS, incluido Azure DNS, y requiere que Azure Front Door valide la propiedad del dominio.

Validación de registro TXT

Para validar un dominio, debe crear un registro TXT de DNS. El nombre del registro TXT debe tener el formato _dnsauth.{subdomain}. Azure Front Door proporciona un valor único para el registro TXT al comienzo de la adición del dominio a Azure Front Door.

Por ejemplo, supongamos que quiere usar el subdominio personalizado myapplication.contoso.com con Azure Front Door. En primer lugar, agregue el dominio al perfil de Azure Front Door y anote el valor del registro TXT que debe usar. Después, configure un registro DNS con las siguientes propiedades:

Propiedad Valor
Nombre de registro _dnsauth.myapplication
Registrar valor use el valor proporcionado por Azure Front Door
Período de vida (TTL) 1 hora

Una vez que el dominio se haya validado correctamente, puede eliminar de forma segura el registro TXT del servidor DNS.

Para más información sobre cómo agregar un registro TXT de DNS para un dominio personalizado, consulte Configurar un dominio personalizado en Azure Front Door mediante el Azure Portal.

Estados de validación del dominio

En la tabla siguiente se enumeran los estados de validación que un dominio podría mostrar.

Estado de validación del dominio Descripción y acciones
Enviando El dominio personalizado se está creando.

Espere hasta que el recurso de dominio esté listo.
Pending Se ha generado el valor del registro TXT de DNS y Azure Front Door está listo para agregar el registro TXT de DNS.

Agregue el registro TXT de DNS al proveedor de DNS y espere a que se complete la validación. Si el estado permanece pendiente incluso después de actualizar el registro TXT con el proveedor DNS, seleccione Regenerar para actualizar el registro TXT y, a continuación, vuelva a agregar el registro TXT al proveedor DNS.
Revalidación pendiente Faltan menos de 45 días para que el certificado administrado expire.

Si tiene un registro CNAME que ya apunta al punto de conexión de Azure Front Door, no se requiere ninguna acción para la renovación del certificado. Si el dominio personalizado apunta a otro registro CNAME, seleccione el estado Pending re-validation (Pendiente de revalidación) y, después, Regenerar en la página Validate the custom domain (Validación del dominio personalizado). Por último, seleccione Agregar si usa Azure DNS o agrega manualmente el registro TXT con la administración de DNS de su propio proveedor DNS.
Actualización del token de validación Un dominio entra en el estado Actualizar token de validación durante un breve período después de seleccionar el botón Regenerar. Una vez que se emite un nuevo valor de registro TXT, el estado cambia a Pendiente.
No se requiere ninguna acción.
Aprobado El dominio se ha validado correctamente y Azure Front Door puede aceptar el tráfico que usa este dominio.

No se requiere ninguna acción.
Rechazada El proveedor de certificados o entidad ha rechazado la emisión del certificado administrado. Por ejemplo, el nombre de dominio podría no ser válido.

Seleccione el vínculo Rechazado y después seleccione Regenerar en la página Validar el dominio personalizado, como se muestra en las capturas de pantalla debajo de esta tabla. Después, seleccione Agregar para agregar el registro TXT en el proveedor DNS.
Tiempo de espera El registro TXT no se agregó al proveedor DNS en un plazo de siete días o se agregó un registro TXT de DNS no válido.

Seleccione el vínculo Tiempo de espera y, a continuación, seleccione Regenerar en la página Validar el dominio personalizado. Después, seleccione Agregar para agregar un registro TXT nuevo en el proveedor DNS. Asegúrese de usar el valor actualizado.
Error interno. Se produjo un error desconocido.

Vuelva a intentarlo seleccionando los botones Actualizar o Regenerar. Si sigue experimentando problemas, envíe una solicitud de soporte técnico al Soporte técnico de Azure.

Nota

  • El TTL predeterminado para registros TXT es de 1 hora. Cuando necesite volver a generar el registro TXT para validarlo de nuevo, preste atención al TTL del registro TXT anterior. Si no expira, se producirá un error en la validación hasta que expire el registro TXT anterior.
  • Si el botón Regenerar no funciona, elimine y vuelva a crear el dominio.
  • Si el estado del dominio no se refleja según lo previsto, seleccione el botón Actualizar.

HTTPS para dominios personalizados

Con el protocolo HTTPS en el dominio personalizado, se garantiza que los datos confidenciales se entreguen de manera segura mediante el cifrado TLS/SSL cuando se envían por Internet. Cuando un cliente, como un explorador web, está conectado a un sitio web mediante HTTPS, el cliente valida el certificado de seguridad del sitio web y garantiza que lo emitió una entidad de certificación legítima. Este proceso aporta seguridad y protege las aplicaciones web de posibles ataques.

Azure Front Door admite el uso de HTTPS con sus propios dominios y descarga la administración de certificados de seguridad de la capa de transporte (TLS) desde los servidores de origen. Al usar dominios personalizados, puede usar certificados TLS administrados por Azure (recomendados) o puede comprar y usar sus propios certificados TLS.

Para más información sobre cómo funciona Azure Front Door con TLS, consulte TLS de un extremo a otro con Azure Front Door.

Certificados TLS administrados por Azure Front Door

Azure Front Door puede administrar certificados TLS para subdominios y dominios de vértice de forma automática. Al usar certificados administrados, no es necesario crear claves ni solicitudes de firma de certificados y tampoco lo es cargar, almacenar ni instalar los certificados. Además, Azure Front Door puede rotar los certificados administrados (renovar) automáticamente sin intervención humana. Este proceso evita el tiempo de inactividad causado por no haber renovado los certificados TLS a tiempo.

El proceso de generación, emisión e instalación de un certificado TLS administrado puede tardar de varios minutos a una hora en completarse y, en ocasiones, puede tardar más.

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 rotar los certificados.

Tipos de dominio

En la tabla siguiente se resumen las características disponibles con certificados TLS administrados cuando se usan distintos tipos de dominios:

Consideración Subdominio Dominio de Apex Dominio con comodín
Certificados TLS administrados disponibles Sí Sí No
Los certificados TLS administrados se rotan automáticamente Sí Consulte a continuación No

Cuando se usan certificados TLS administrados por Azure Front Door con dominios de vértice, la rotación de certificados automatizada puede requerir que vuelva a validar la propiedad del dominio. Para obtener más información, consulte Dominios de vértice en Azure Front Door.

Emisión de certificados administrados

Los certificados de Azure Front Door los emite nuestra entidad de certificación asociada, DigiCert. En algunos dominios, debe permitir explícitamente DigiCert como emisor de certificados mediante la creación de un registro de dominio de CAA con el valor 0 issue digicert.com.

Azure administra completamente los certificados en nombre del usuario, por lo que cualquier dato relacionado con el certificado administrado, incluido el emisor raíz, se puede cambiar en cualquier momento. Estos cambios se producen al margen del usuario. Asegúrese de evitar dependencias difíciles en cualquier aspecto de un certificado administrado, como comprobar la huella digital del certificado o anclar el certificado administrado o cualquier parte de la jerarquía de certificados. Si necesita anclar certificados, use un certificado TLS administrado por el cliente, como se explica en la sección siguiente.

Certificados TLS administrados por el cliente

A veces, es posible que tenga que proporcionar sus propios certificados TLS. Entre los escenarios comunes para proporcionar sus propios certificados se incluyen los siguientes:

  • Su organización requiere que use certificados emitidos por una entidad de certificación específica.
  • Quiere que Azure Key Vault emita el certificado mediante una entidad de certificación asociada.
  • Debe usar un certificado TLS que una aplicación cliente reconozca.
  • Debe usar el mismo certificado TLS en varios sistemas.
  • Usa dominios con caracteres comodín. Azure Front Door no proporciona certificados administrados para dominios con caracteres comodín.

Nota:

  • A partir de septiembre de 2023, Azure Front Door admite Bring Your Own Certificates (BYOC) para la validación de la propiedad del dominio. Front Door aprobará automáticamente la propiedad del dominio si el nombre del certificado (CN) o el nombre alternativo del firmante (SAN) del certificado coincide con el dominio personalizado. Si selecciona un certificado administrado por Azure, la validación del dominio usará el registro TXT de DNS.
  • En el caso de los dominios personalizados creados antes de la validación basada en BYOC y de que el estado de validación del dominio no sea Aprobado, debe desencadenar la aprobación automática de la validación de la propiedad del dominio. Para ello, seleccione el Estado de validación y, a continuación, haga clic en el botón Volver a validar en el portal. Si usa la herramienta de línea de comandos, puede desencadenar la validación de dominio mediante el envío de una solicitud PATCH vacía a la API de dominio.

Requisitos de certificados

Para usar el certificado con Azure Front Door, debe cumplir los siguientes requisitos:

  • Cadena de certificados completa: 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 rechaza. 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.
  • Nombre común: el nombre común (CN) del certificado debe coincidir con el dominio configurado en Azure Front Door.
  • Algoritmo: Azure Front Door no admite certificados con algoritmos de criptografía de curva elíptica (EC).
  • Tipo de archivo (contenido): el certificado debe cargarse en el almacén de claves desde un archivo PFX, que usa el tipo de contenido application/x-pkcs12.

Importación de un certificado a Azure Key Vault

Los certificados TLS personalizados se deben importar a Azure Key Vault para poder usarlos con Azure Front Door. Para obtener información sobre cómo importar un certificado a un almacén de claves, consulte Tutorial: Importación de un certificado en Azure Key Vault.

El almacén de claves debe estar en la misma suscripción de Azure que el perfil de Azure Front Door.

Advertencia

Azure Front Door solo admite almacenes de claves en la misma suscripción que el perfil de Front Door. Si elige un almacén de claves de una suscripción diferente a la de Azure Front Door, se producirá un error.

Los certificados se deben cargar como un objeto de certificado, en lugar de un secreto.

Concesión de acceso a Azure Front Door

Azure Front Door debe acceder al almacén de claves para leer el certificado. Debe configurar tanto el firewall de red del almacén de claves como el control de acceso del almacén.

Si el almacén de claves tiene habilitadas restricciones de acceso a la red, debe configurar el almacén de claves para permitir que los servicios de Microsoft de confianza eludan el firewall.

Hay dos formas de configurar el control de acceso en el almacén de claves:

  • Azure Front Door puede usar una identidad administrada para acceder al almacén de claves. Puede usar este enfoque cuando el almacén de claves use la autenticación de Microsoft Entra. Para más información, consulte Uso de identidades administradas con Azure Front Door Estándar/Premium (versión preliminar).
  • Como alternativa, puede conceder acceso al almacén de claves a la entidad de servicio de Azure Front Door. Puede usar este enfoque al usar directivas de acceso al almacén.

Incorporación del certificado personalizado a Azure Front Door

Después de importar el certificado a un almacén de claves, cree un recurso secreto de Azure Front Door, que es una referencia al certificado que agregó al almacén de claves.

Después, configure el dominio para que use el secreto de Azure Front Door para su certificado TLS.

Para obtener un recorrido guiado por estos pasos, consulte Configuración de HTTPS en un dominio personalizado de Azure Front Door mediante el Azure Portal.

Intercambio entre tipos de certificado

Puede cambiar un dominio entre el uso de un certificado administrado por Azure Front Door y uno administrado por el usuario.

  • El nuevo certificado puede tardar hasta una hora en implementarse al cambiar entre los tipos de certificado.
  • Si el estado del dominio es Aprobado, cambiar el tipo de certificado entre uno administrado por el usuario y uno administrado no causará tiempo de inactividad.
  • Al cambiar a un certificado administrado, Azure Front Door sigue usando el certificado anterior hasta que la propiedad del dominio se vuelva a validar y su estado se convierta en Aprobado.
  • Si cambia de BYOC a certificado administrado, es necesario volver a validar el dominio. Si cambia de certificado administrado a BYOC, no es necesario volver a validar el dominio.

Renovación de certificados

Renovación de certificados administrados por Azure Front Door

Para la mayoría de los dominios personalizados, Azure Front Door renueva los certificados administrados (rotaciones) automáticamente cuando están a punto de expirar y no es necesario hacer nada.

Pero Azure Front Door no rotará los certificados automáticamente en los escenarios siguientes:

  • El registro CNAME del dominio personalizado apunta a un registro DNS distinto del dominio del punto de conexión de Azure Front Door.
  • Si el dominio personalizado apunta al punto de conexión de Azure Front Door mediante una cadena. Por ejemplo, si el registro DNS apunta a Azure Traffic Manager, que a su vez se resuelve en Azure Front Door, la cadena CNAME es CNAME contoso.com en CNAME contoso.trafficmanager.net en contoso.z01.azurefd.net. Azure Front Door no puede comprobar toda la cadena.
  • El dominio personalizado usa un registro A. Se recomienda usar siempre un registro CNAME para apuntar a Azure Front Door.
  • El dominio personalizado es un dominio de vértice y usa acoplamiento CNAME.

Si uno de los escenarios anteriores se aplica al dominio personalizado, 45 días antes de que el certificado administrado expire, el estado de validación del dominio se convierte en Pendiente de revalidación. El estado Pendiente de revalidación indica que debe crear un nuevo registro TXT de DNS para volver a validar la propiedad del dominio.

Nota

Los registros TXT de DNS expiran después de siete días. Si anteriormente agregó un registro TXT de validación de dominio al servidor DNS, debe reemplazarlo por uno nuevo. Asegúrese de usar el valor nuevo; de lo contrario, se producirá un error en el proceso de validación del dominio.

Si el dominio no se puede validar, el estado de validación del dominio se convierte en Rechazado. Este estado indica que la entidad de certificación ha rechazado la solicitud de volver a emitir un certificado administrado.

Para obtener más información sobre los estados de validación de dominio, consulte Estados de validación del dominio.

Renovación de certificados administrados por Azure para dominios validados previamente por otros servicios de Azure

El servicio de Azure rota automáticamente los certificados administrados por Azure que el dominio valida.

Renovación de certificados TLS administrados por el cliente

Al actualizar el certificado en el almacén de claves, Azure Front Door puede detectar y usar de forma automática el certificado actualizado. Para que esta funcionalidad funcione, establezca la versión secreta en "Más reciente" al configurar el certificado en Azure Front Door.

Si selecciona una versión específica del certificado, debe volver a seleccionar la versión nueva manualmente al actualizar el certificado.

La nueva versión del certificado o el secreto tarda hasta 72 horas en implementarse automáticamente.

Si desea cambiar la versión del secreto de "Más reciente" a una versión especificada o viceversa, agregue un nuevo certificado.

Directivas de seguridad

Puede usar el firewall de aplicaciones web (WAF) de Azure Front Door para examinar las solicitudes a la aplicación en busca de amenazas y aplicar otros requisitos de seguridad.

Para usar WAF con un dominio personalizado, use un recurso de directiva de seguridad de Azure Front Door. Una directiva de seguridad asocia un dominio a una directiva WAF. Opcionalmente, puede crear varias directivas de seguridad para que pueda usar directivas WAF distintas con dominios diferentes.

Pasos siguientes