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.
Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), is the standard security technology for establishing an encrypted link between a web server and a client, like a web browser. This link ensures that all data passed between the server and the client remains private and encrypted.
To meet your security or compliance requirements, Azure Front Door supports end-to-end TLS encryption. Front Door TLS/SSL offload terminates the TLS connection, decrypts the traffic at the Azure Front Door, and re-encrypts the traffic before forwarding it to the origin. When connections to the origin use the origin's public IP address, it's a good security practice to configure HTTPS as the forwarding protocol on your Azure Front Door. By using HTTPS as the forwarding protocol, you can enforce end-to-end TLS encryption for the entire processing of the request from the client to the origin. TLS/SSL offload is also supported if you deploy a private origin with Azure Front Door Premium using the Private Link feature.
This article explains how Azure Front Door works with TLS connections. For more information about how to use TLS certificates with your own custom domains, see HTTPS for custom domains. To learn how to configure a TLS certificate on your own custom domain, see Configure a custom domain on Azure Front Door using the Azure portal.
End-to-end TLS encryption
End-to-end TLS encryption secures sensitive data while in transit to the origin and enables you to benefit from Azure Front Door features like global load balancing and caching. Some of the features also include URL-based routing, TCP split, caching on edge location closest to the clients, and customizing HTTP requests at the edge.
Azure Front Door offloads the TLS sessions at the edge and decrypts client requests. It then applies the configured routing rules to route the requests to the appropriate origin in the origin group. Azure Front Door then starts a new TLS connection to the origin and re-encrypts all data using the origin's certificate before transmitting the request to the origin. Any response from the origin is encrypted through the same process back to the end user. You can configure your Azure Front Door to use HTTPS as the forwarding protocol to enable end-to-end TLS.
Supported TLS versions
Azure Front Door supports two versions of the TLS protocol: TLS versions 1.2 and 1.3. All Azure Front Door profiles created after September 2019 use TLS 1.2 as the default minimum with TLS 1.3 enabled. Currently, Azure Front Door doesn't support client/mutual authentication (mTLS).
Important
TLS 1.0 and 1.1 aren't supported.
For Azure Front Door Standard and Premium, you can configure a predefined TLS policy or choose the TLS cipher suite based on your organization's security needs. For more information, see Configure an Azure Front Door TLS policy.
Note
- Clients with TLS 1.3 enabled must support one of the Microsoft SDL compliant EC Curves, including Secp384r1, Secp256r1, and Secp521, to successfully make requests with Azure Front Door using TLS 1.3.
- Use one of these curves as the preferred curve during requests to avoid increased TLS handshake latency, which might result from multiple round trips to negotiate the supported EC curve.
Supported certificates
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 non-allowed CA, Azure Front Door rejects your request.
Certificates from internal CAs or self-signed certificates aren't allowed.
Online Certificate Status Protocol (OCSP) stapling
Azure Front Door supports OCSP stapling by default and requires no configuration.
Origin TLS connection (Azure Front Door to origin)
For HTTPS connections, Azure Front Door expects your origin to present a certificate from a valid certificate authority (CA) with a subject name that matches the origin hostname. For example, if you set your origin hostname to myapp-chinanorth2.contoso.net but the certificate your origin presents during the TLS handshake doesn't include myapp-chinanorth2.contoso.net or *.contoso.net in the subject name, Azure Front Door refuses the connection and the client sees an error.
Note
The certificate must include a complete certificate chain with leaf and intermediate certificates. The root CA must be part of the Microsoft Trusted CA List. If you present a certificate without a complete chain, requests that involve that certificate might not work as expected.
In certain use cases, such as testing, you can disable certificate subject name checks for your Azure Front Door as a workaround to resolve failing HTTPS connections. The origin must still present a certificate with a valid, trusted chain, but it doesn't need to match the origin hostname.
In Azure Front Door Standard and Premium, you can configure an origin to disable the certificate subject name check.
Note
From a security standpoint, don't disable the certificate subject name check.
Frontend TLS connection (client to Azure Front Door)
To enable the HTTPS protocol for secure delivery of content on an Azure Front Door custom domain, use either a certificate that Azure Front Door manages or your own certificate.
For more information, see HTTPS for custom domains.