freshness

halkazwini · halkazwini · commit bf611ee3c4eb · 2025-03-18T14:50:59.000-05:00
diff --git a/articles/frontdoor/TOC.yml b/articles/frontdoor/TOC.yml
@@ -193,7 +193,7 @@
     href: /security/benchmark/azure/baselines/azure-front-door-security-baseline?toc=/azure/frontdoor/TOC.json
   - name: DDoS protection
     href: front-door-ddos.md
-  - name: About TLS encryption
+  - name: End-to-end TLS encryption
     href: end-to-end-tls.md
   - name: Set up managed identity
     href: managed-identity.md
diff --git a/articles/frontdoor/end-to-end-tls.md b/articles/frontdoor/end-to-end-tls.md
@@ -1,19 +1,16 @@
 ---
-title: 'About TLS encryption with Azure Front Door'
-description: Learn about TLS encryption when using Azure Front Door.
+title: TLS encryption with Azure Front Door
+description: Learn about end-to-end TLS encryption, supported TLS versions, and supported cipher suites with Azure Front Door.
 author: halkazwini
 ms.author: halkazwini
 ms.service: azure-frontdoor
 ms.topic: concept-article
-ms.date: 03/15/2024
+ms.date: 03/18/2025
 zone_pivot_groups: front-door-tiers
 ---
 
 # About TLS encryption with Azure Front Door
 
-> [!IMPORTANT]
-> Support for TLS 1.0 and 1.1 will be discontinued on March 1, 2025.
-
 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 remain 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](private-link.md) feature.
@@ -32,15 +29,16 @@ Azure Front Door offloads the TLS sessions at the edge and decrypts client reque
 
 ## Supported TLS versions
 
-Azure Front Door currently supports four versions of the TLS protocol: TLS versions 1.0, 1.1, 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, but TLS 1.0 and TLS 1.1 are still supported for backward compatibility. Support for TLS 1.0 and 1.1 will be discontinued on March 1, 2025.
+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, with support for TLS 1.0 and TLS 1.1 for backward compatibility. Currently, Azure Front Door doesn't support client/mutual authentication (mTLS).
 
-Although Azure Front Door supports TLS 1.2, which introduced client/mutual authentication in RFC 5246, currently, Azure Front Door doesn't support client/mutual authentication (mTLS) yet.
+> [!IMPORTANT]
+> As of March 1, 2025, TLS 1.0 and 1.1 are disallowed on Azure Front Door. If you didn't disable TLS 1.0 and 1.1 on legacy settings before this date, they'll still work temporarily but will be disabled in the future.
 
-You can configure the minimum TLS version in Azure Front Door in the custom domain HTTPS settings using the Azure portal or the [Azure REST API](/rest/api/frontdoorservice/frontdoor/frontdoors/createorupdate#minimumtlsversion). Currently, you can choose between 1.0 and 1.2. As such, specifying TLS 1.2 as the minimum version controls the minimum acceptable TLS version Azure Front Door will accept from a client. For minimum TLS version 1.2 the negotiation will attempt to establish TLS 1.3 and then TLS 1.2, while for minimum TLS version 1.0 all four versions will be attempted. When Azure Front Door initiates TLS traffic to the origin, it will attempt to negotiate the best TLS version that the origin can reliably and consistently accept. Supported TLS versions for origin connections are TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3. Support for TLS 1.0 and 1.1 will be discontinued on March 1, 2025.
+You can configure the minimum TLS version in Azure Front Door in the custom domain HTTPS settings using the Azure portal or the [Azure REST API](/rest/api/frontdoorservice/frontdoor/frontdoors/createorupdate#minimumtlsversion). For a minimum TLS version 1.2, the negotiation will attempt to establish TLS 1.3 and then TLS 1.2. When Azure Front Door initiates TLS traffic to the origin, it will attempt to negotiate the best TLS version that the origin can reliably and consistently accept. Supported TLS versions for origin connections are TLS 1.2 and TLS 1.3.
 
 > [!NOTE]
-> * Clients with TLS 1.3 enabled are required to support one of the Microsoft SDL compliant EC Curves, including Secp384r1, Secp256r1, and Secp521, in order to successfully make requests with Azure Front Door using TLS 1.3.
-> * It is recommended that clients use one of these curves as their preferred curve during requests to avoid increased TLS handshake latency, which may result from multiple round trips to negotiate the supported EC curve.
+> - Clients with TLS 1.3 enabled are required to support one of the Microsoft SDL compliant EC Curves, including Secp384r1, Secp256r1, and Secp521, in order to successfully make requests with Azure Front Door using TLS 1.3.
+> - It is recommended that clients use one of these curves as their preferred curve during requests to avoid increased TLS handshake latency, which may result from multiple round trips to negotiate the supported EC curve.
 
 ## Supported certificates
 
@@ -54,12 +52,12 @@ OCSP stapling is supported by default in Azure Front Door and no configuration i
 
 ## <a name="backend-tls-connection-azure-front-door-to-origin"></a> Origin TLS connection (Azure Front Door to origin)
 
-For HTTPS connections, Azure Front Door expects that your origin presents a certificate from a valid certificate authority (CA) with a subject name matching the origin *hostname*. As an example, if your origin hostname is set to `myapp-centralus.contosonews.net` and the certificate that your origin presents during the TLS handshake doesn't have `myapp-centralus.contosonews.net` or `*.contosonews.net` in the subject name, then Azure Front Door refuses the connection and the client sees an error.
+For HTTPS connections, Azure Front Door expects that your origin presents a certificate from a valid certificate authority (CA) with a subject name matching the origin *hostname*. As an example, if your origin hostname is set to `myapp-centralus.contoso.net` and the certificate that your origin presents during the TLS handshake doesn't have `myapp-centralus.contoso.net` or `*.contoso.net` in the subject name, then Azure Front Door refuses the connection and the client sees an error.
 
 > [!NOTE]
-> The certificate must have a complete certificate chain with leaf and intermediate certificates. The root CA must be part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT). If a certificate without complete chain is presented, the requests which involve that certificate are not guaranteed to work as expected.
+> The certificate must have a complete certificate chain with leaf and intermediate certificates. The root CA must be part of the [Microsoft Trusted CA List](https://ccadb.my.salesforce-sites.com/microsoft/IncludedCACertificateReportForMSFT). If a certificate without complete chain is presented, the requests which involve that certificate are not guaranteed to work as expected.
 
-In certain use cases such as for testing, as a workaround to resolve failing HTTPS connection, you can disable certificate subject name check for your Azure Front Door. Note that the origin still needs to present a certificate with a valid trusted chain, but doesn't have to match the origin host name.
+In certain use cases, such as testing, you can disable certificate subject name checks for your Azure Front Door as a workaround for resolving failing HTTPS connections. Note that the origin must still present a certificate with a valid, trusted chain, but it doesn't need to match the origin hostname.
 
 ::: zone pivot="front-door-standard-premium"
 
@@ -100,64 +98,45 @@ For the Azure Front Door managed certificate option, the certificates are manage
 
 For your own custom TLS/SSL certificate:
 
-1. You set the secret version to 'Latest' for the certificate to be automatically rotated to the latest version when a newer version of the certificate is available in your key vault. For custom certificates, the certificate gets auto-rotated within 3-4 days with a newer version of certificate, no matter what the certificate expired time is.
+1. Set the secret version to 'Latest' for the certificate to be automatically rotated to the latest version when a newer version of the certificate is available in your key vault. For custom certificates, the certificate gets auto-rotated within 3-4 days with a newer version of certificate, no matter what the certificate expired time is.
 
-1. If a specific version is selected, autorotation isn’t supported. You've will have to reselect the new version manually to rotate certificate. It takes up to 24 hours for the new version of the certificate/secret to be deployed.
+1. If a specific version is selected, autorotation isn’t supported. You'll have to reselect the new version manually to rotate certificate. It takes up to 24 hours for the new version of the certificate/secret to be deployed.
 
     > [!NOTE]
     > Azure Front Door (Standard and Premium) managed certificates are automatically rotated if the domain CNAME record points directly to a Front Door endpoint or points indirectly to a Traffic Manager endpoint. Otherwise, you need to re-validate the domain ownership to rotate the certificates.
 
-    You'll need to ensure that the service principal for Front Door has access to the key vault. Refer to how to grant access to your key vault. The updated certificate rollout operation by Azure Front Door won't cause any production downtime, as long as the subject name or subject alternate name (SAN) for the certificate hasn't changed.
+    The service principal for Front Door must have access to the key vault. The updated certificate rollout operation by Azure Front Door won't cause any production downtime, as long as the subject name or subject alternate name (SAN) for the certificate hasn't changed.
 
 ## Supported cipher suites
 
 For TLS 1.2/1.3 the following cipher suites are supported:
-* TLS_AES_256_GCM_SHA384 (TLS 1.3 only)
-* TLS_AES_128_GCM_SHA256 (TLS 1.3 only)
-* 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
 
-> [!NOTE]
-> For Windows 10 and later versions, we recommend enabling one or both of the ECDHE_GCM cipher suites for better security. Windows 8.1, 8, and 7 aren't compatible with these ECDHE_GCM cipher suites. The ECDHE_CBC and DHE cipher suites have been provided for compatibility with those operating systems. 
-
-When using custom domains with TLS 1.0 and 1.1 enabled, the following cipher suites are supported:
-
-* TLS_AES_256_GCM_SHA384 (TLS 1.3 only)
-* TLS_AES_128_GCM_SHA256 (TLS 1.3 only)
-* 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
+- TLS_AES_256_GCM_SHA384 (TLS 1.3 only)
+- TLS_AES_128_GCM_SHA256 (TLS 1.3 only)
+- 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
 
 Azure Front Door doesn’t support disabling or configuring specific cipher suites for your profile.
 
-## Next steps
+> [!NOTE]
+> For Windows 10 and later versions, we recommend enabling one or both of the ECDHE_GCM cipher suites for better security. Windows 8.1, 8, and 7 aren't compatible with these ECDHE_GCM cipher suites. The ECDHE_CBC and DHE cipher suites have been provided for compatibility with those operating systems. 
+
+## Related content
 
 ::: zone pivot="front-door-standard-premium"
 
-* [Understand custom domains](domain.md) on Azure Front Door.
-* [Configure a custom domain](standard-premium/how-to-add-custom-domain.md) on Azure Front Door using the Azure portal.
-* Learn about [End-to-end TLS with Azure Front Door](end-to-end-tls.md).
+- [Domains in Azure Front Door](domain.md)
+- [Configure a custom domain on Azure Front Door](standard-premium/how-to-add-custom-domain.md)
 
 ::: zone-end
 
 ::: zone pivot="front-door-classic"
 
-* [Configure a custom domain](front-door-custom-domain.md) for Azure Front Door.
-* [Enable HTTPS for a custom domain](front-door-custom-domain-https.md).
+- [Configure a custom domain for Azure Front Door (classic)](front-door-custom-domain.md) 
+- [Configure HTTPS on an Azure Front Door (classic) custom domain](front-door-custom-domain-https.md)
 
 ::: zone-end
