Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: ✔️ Front Door Standard ✔️ Front Door Premium
A domain represents a custom domain name that Azure Front Door uses to receive your application's traffic. Azure Front Door supports adding three types of domain names:
- Subdomains are the most common type of custom domain name. An example subdomain is
myapplication.contoso.com. - Apex domains don't contain a subdomain. An example apex domain is
contoso.com. For more information about using apex domains with Azure Front Door, see Apex domains. - Wildcard domains allow traffic to be received for any subdomain. An example wildcard domain is
*.contoso.com. For more information about using wildcard domains with Azure Front Door, see Wildcard domains.
Add domains to your Azure Front Door profile. You can use a domain in multiple routes within an endpoint if you use different paths in each route.
To learn how to add a custom domain to your Azure Front Door profile, see Configure a custom domain on Azure Front Door using the Azure portal.
DNS configuration
When you add a domain to your Azure Front Door profile, you configure two records in your DNS server:
- A DNS TXT record, which is required to validate ownership of your domain name. For more information on the DNS TXT records, see Domain validation.
- A DNS CNAME record, which controls the flow of internet traffic to Azure Front Door.
Tip
You can add a domain name to your Azure Front Door profile before making any DNS changes. This approach can be helpful if you need to set your Azure Front Door configuration together, or if you have a separate team that changes your DNS records.
You can also add your DNS TXT record to validate your domain ownership before you add the CNAME record to control traffic flow. This approach can help you avoid experiencing migration downtime if you have an application already in production.
Domain validation
You must validate all domains you add to Azure Front Door. Validation helps protect you from accidental misconfiguration and also helps protect other people from domain spoofing. In some situations, another Azure service can prevalidate domains. Otherwise, you need to follow the Azure Front Door domain validation process to prove your ownership of the domain name.
Azure prevalidated domains are domains that another supported Azure service validates. If you onboard and validate a domain to another Azure service, and then configure Azure Front Door later, you might work with a prevalidated domain. You don't need to validate the domain through Azure Front Door when you use this type of domain.
Note
Azure Front Door currently only accepts pre-validated domains that have been configured with Azure Static Web Apps.
Non-Azure validated domains are domains that a supported Azure service doesn't validate. You can host this domain type with any DNS service, including Azure DNS and must validate its ownership by Azure Front Door.
TXT record validation
To validate a domain, create a DNS TXT record. The name of the TXT record must be of the form _dnsauth.{subdomain}. Azure Front Door provides a unique value for your TXT record when you start to add the domain to Azure Front Door.
For example, suppose you want to use the custom subdomain myapplication.contoso.com with Azure Front Door. First, add the domain to your Azure Front Door profile, and note the TXT record value that you need to use. Then, configure a DNS record with the following properties:
| Property | Value |
|---|---|
| Record name | _dnsauth.myapplication |
| Record value | use the value provided by Azure Front Door |
| Time to live (TTL) | 1 hour |
After your domain is validated successfully, you can safely delete the TXT record from your DNS server.
For more information about adding a DNS TXT record for a custom domain, see Configure a custom domain on Azure Front Door using the Azure portal.
Domain validation states
The following table lists the validation states that a domain might show.
| Domain validation state | Description and actions |
|---|---|
| Submitting | The custom domain is being created. Wait until the domain resource is ready. |
| Pending | The DNS TXT record value is generated, and Azure Front Door is ready for you to add the DNS TXT record. Add the DNS TXT record to your DNS provider and wait for the validation to complete. If the status remains Pending even after the TXT record is updated by the DNS provider, select Regenerate to refresh the TXT record, and then add the TXT record to your DNS provider again. |
| Pending revalidation | The managed certificate is less than 45 days from expiring. If you have a CNAME record already pointing to the Azure Front Door endpoint, no action is required for certificate renewal. If the custom domain points to another CNAME record, select the Pending re-validation status, and then select Regenerate on the Validate the custom domain page. Lastly, select Add if you're using Azure DNS or manually add the TXT record with your own DNS provider’s DNS management. |
| Refreshing validation token | A domain goes into a Refreshing Validation Token state for a brief period after the Regenerate button is selected. Once a new TXT record value is issued, the state changes to Pending. No action is required. |
| Approved | The domain is successfully validated, and Azure Front Door can accept traffic that uses this domain. No action is required. |
| Rejected | The certificate provider or authority rejected the issuance for the managed certificate. For example, the domain name might be invalid. Select the Rejected link and then select Regenerate on the Validate the custom domain page. Then, select Add to add the TXT record in the DNS provider. |
| Timeout | The TXT record isn't added to your DNS provider within seven days, or an invalid DNS TXT record is added. Select the Timeout link and then select Regenerate on the Validate the custom domain page. Then select Add to add a new TXT record to the DNS provider. Ensure that you use the updated value. |
| Internal error | An unknown error occurred. Retry validation by selecting the Refresh or Regenerate button. If you're still experiencing issues, submit a support request to Azure support. |
Note
- The default TTL for TXT records is one hour. When you need to regenerate the TXT record for revalidation, pay attention to the TTL for the previous TXT record. If it doesn't expire, the validation fails until the previous TXT record expires.
- If the Regenerate button doesn't work, delete and recreate the domain.
- If the domain state doesn't reflect as expected, select the Refresh button.
HTTPS for custom domains
By using the HTTPS protocol on your custom domain, you ensure your sensitive data is delivered securely by using TLS/SSL encryption when it's sent across the internet. When a client, like a web browser, connects to a website by using HTTPS, the client validates the website's security certificate, and ensures it was issued by a legitimate certificate authority. This process provides security and protects your web applications from attacks.
Azure Front Door supports using HTTPS with your own domains, and offloads transport layer security (TLS) certificate management from your origin servers. When you use custom domains, you can purchase and use your own TLS certificates.
For more information on how Azure Front Door works with TLS, see End-to-end TLS with Azure Front Door.
Customer-managed TLS certificates
Sometimes, you need to provide your own TLS certificates. Common scenarios for providing your own certificates include:
- Your organization requires you to use certificates issued by a specific certification authority.
- You want Azure Key Vault to issue your certificate by using a partner certification authority.
- You need to use a TLS certificate that a client application recognizes.
- You need to use the same TLS certificate on multiple systems.
Note
- Azure Front Door supports Bring Your Own Certificates (BYOC) for domain ownership validation. Front Door approves the domain ownership if the Certificate Name (CN) or Subject Alternative Name (SAN) of the certificate matches the custom domain.
- For custom domains created before BYOC based validation, and the domain validation status isn't Approved, you need to trigger the auto approval of the domain ownership validation by selecting the Validation State and clicking on the Revalidate button in the portal. If you use the command line tool, you can trigger domain validation by sending an empty PATCH request to the domain API.
Certificate requirements
To use your certificate with Azure Front Door, it must meet the following requirements:
- Complete certificate chain: When you create your TLS/SSL certificate, you must create a complete certificate chain with an allowed certificate authority (CA) that is part of the Microsoft Trusted CA List. If you use a nonallowed CA, your request is rejected. The root CA must be part of the Microsoft Trusted CA List. If a certificate without complete chain is presented, the requests that involve that certificate aren't guaranteed to work as expected.
- Common name: The common name (CN) of the certificate must match the domain configured in Azure Front Door.
- Algorithm: Azure Front Door doesn't support certificates with elliptic curve (EC) cryptography algorithms.
- File (content) type: You must upload your certificate to your key vault from a PFX file, which uses the
application/x-pkcs12content type.
Import a certificate to Azure Key Vault
You must import custom TLS certificates into Azure Key Vault before you can use them with Azure Front Door. To learn how to import a certificate to a key vault, see Tutorial: Import a certificate in Azure Key Vault.
The key vault must be in the same Azure subscription as your Azure Front Door profile.
Warning
Azure Front Door only supports key vaults in the same subscription as the Front Door profile. Choosing a key vault under a different subscription than your Azure Front Door profile results in a failure.
You must upload certificates as a certificate object, rather than a secret.
Grant access to Azure Front Door
Azure Front Door needs to access your key vault to read your certificate. You need to configure both the key vault's network firewall and the vault's access control.
If your key vault has network access restrictions enabled, you must configure your key vault to allow trusted Microsoft services to bypass the firewall.
You can configure access control on your key vault in two ways:
- Azure Front Door can use a managed identity to access your key vault. You can use this approach when your key vault uses Microsoft Entra authentication. For more information, see Use managed identities with Azure Front Door Standard/Premium.
- Alternatively, you can grant Azure Front Door's service principal access to your key vault. You can use this approach when you use vault access policies.
Add your custom certificate to Azure Front Door
After you import your certificate to a key vault, create an Azure Front Door secret resource, which is a reference to the certificate you added to your key vault.
Then, configure your domain to use the Azure Front Door secret for its TLS certificate.
For a guided walkthrough of these steps, see Configure HTTPS on an Azure Front Door custom domain using the Azure portal.
Certificate renewal
Renew customer-managed TLS certificates
When you update the certificate in your key vault, Azure Front Door can automatically detect and use the updated certificate. For this functionality to work, set the secret version to Latest when you configure your certificate in Azure Front Door.
If you select a specific version of your certificate, you must manually reselect the new version when you update your certificate.
It takes up to 72 hours for the new version of the certificate or secret to be automatically deployed.
If you want to change the secret version from Latest to a specified version or vice versa, add a new certificate.
Security policies
Use Azure Front Door's web application firewall (WAF) to scan requests to your application for threats and enforce other security requirements.
To use the WAF with a custom domain, use an Azure Front Door security policy resource. A security policy associates a domain with a WAF policy. You can optionally create multiple security policies so that you can use different WAF policies with different domains.