Updates from PR review

johndowns · johndowns · commit 543c5b4b6f9d · 2023-02-07T11:51:55.000+13:00
diff --git a/articles/frontdoor/end-to-end-tls.md b/articles/frontdoor/end-to-end-tls.md
@@ -8,27 +8,34 @@ ms.topic: article
 ms.workload: infrastructure-services
 ms.date: 02/01/2023
 ms.author: duau
+zone_pivot_groups: front-door-tiers
 ---
 
 # End-to-end TLS with Azure Front Door
 
 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 (AFD) 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 backend. Since connections to the backend happen over the public IP, it is highly recommended you configure HTTPS as the forwarding protocol on your Azure Front Door to enforce end-to-end TLS encryption from the client to the backend. TLS/SSL offload is also supported if you deploy a private backend with AFD Premium using the [PrivateLink](private-link.md) feature.
+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.
+
+::: zone pivot="front-door-standard-premium"
+
+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](domain.md#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](standard-premium/how-to-add-custom-domain.md).
+
+::: zone-end
 
 ## End-to-end TLS encryption
 
-End-to-end TLS allows you to secure sensitive data while in transit to the backend while benefiting 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.
+End-to-end TLS allows you to secure sensitive data while in transit to the origin while benefiting 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 backend in the backend pool. Azure Front Door then starts a new TLS connection to the backend and re-encrypts all data using the backend’s certificate before transmitting the request to the backend. Any response from the backend 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.
+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 three versions of the TLS protocol: TLS versions 1.0, 1.1, and 1.2. All Azure Front Door profiles created after September 2019 use TLS 1.2 as the default minimum, but TLS 1.0 and TLS 1.1 are still supported for backward compatibility.
 
 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.
 
-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. When Azure Front Door initiates TLS traffic to the backend, it will attempt to negotiate the best TLS version that the backend can reliably and consistently accept.
+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. 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 certificates
 
@@ -40,27 +47,47 @@ Certificates from internal CAs or self-signed certificates aren't allowed.
 
 OCSP stapling is supported by default in Azure Front Door and no configuration is required.
 
-## Backend TLS connection (Azure Front Door to backend)
+## <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 backend presents a certificate from a valid Certificate Authority (CA) with subject name(s) matching the backend *hostname*. As an example, if your backend hostname is set to `myapp-centralus.contosonews.net` and the certificate that your backend presents during the TLS handshake doesn't have `myapp-centralus.contosonews.net` or `*.contosonews.net` in the subject name, then Azure Front Door will refuse the connection and as a result 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.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.
 
 > [!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.
 
-From a security standpoint, Microsoft doesn't recommend disabling certificate subject name check. In certain use cases such as for testing, as a work-around 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. The option to disable this feature is different for each Azure Front Door tier:
+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.
+
+::: zone pivot="front-door-standard-premium"
+
+In Azure Front Door Standard and Premium, you can configure an origin to disable the certificate subject name check.
+
+::: zone-end
+
+::: zone pivot="front-door-classic"
+
+In Azure Front Door (classic), you can configure disable the certificate subject name check by changing the Azure Front Door settings in the Azure portal. You can also configure the check by using the backend pool's settings in the Azure Front Door APIs.
+
+::: zone-end
+
+> [!NOTE]
+> From a security standpoint, Microsoft doesn't recommend disabling the certificate subject name check.
+
+## Frontend TLS connection (client to Azure Front Door)
+
+To enable the HTTPS protocol for secure delivery of contents on an Azure Front Door custom domain, you can choose to use a certificate that is managed by Azure Front Door or use your own certificate.
 
-* Azure Front Door Standard and Premium - it is present in the origin settings.
-* Azure Front Door (classic) - it is present under the Azure Front Door settings in the Azure portal and in the Backend PoolsSettings in the Azure Front Door API.
+::: zone pivot="front-door-standard-premium"
 
-## Frontend TLS connection (Client to Front Door)
+For more information, see [HTTPS for custom domains](domain.md#https-for-custom-domains).
 
-To enable the HTTPS protocol for secure delivery of contents on an Azure Front Door custom domain, you can choose to use a certificate that is managed by Azure Front Door or use your own certificate.  
+::: zone-end
 
-* Azure Front Door managed certificate provides a standard TLS/SSL certificate via DigiCert and is stored in Azure Front Door's Key Vault.   
+::: zone pivot="front-door-classic"
 
-* If you choose to use your own certificate, you can onboard a certificate from a supported CA that can be a standard TLS, extended validation certificate, or even a wildcard certificate.  
+Azure Front Door's managed certificate provides a standard TLS/SSL certificate via DigiCert and is stored in Azure Front Door's Key Vault.   
 
-* Self-signed certificates aren't supported. Learn [how to enable HTTPS for a custom domain](front-door-custom-domain-https.md).
+If you choose to use your own certificate, you can onboard a certificate from a supported CA that can be a standard TLS, extended validation certificate, or even a wildcard certificate. Self-signed certificates aren't supported. Learn [how to enable HTTPS for a custom domain](front-door-custom-domain-https.md).
+
+::: zone-end
 
 ### Certificate autorotation
 
@@ -106,7 +133,19 @@ Using custom domains with TLS1.0/1.1 enabled the following cipher suites are sup
 * TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 
 Azure Front Door doesn’t support configuring specific cipher suites.
+
 ## Next steps
 
+::: zone pivot="front-door-standard-premium"
+
+* [Understand custom domains](domain.md) on Azure Front Door.
+* [Configure a custom domain on Azure Front Door using the Azure portal](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).
+
+::: zone-end
diff --git a/articles/frontdoor/front-door-custom-domain-https.md b/articles/frontdoor/front-door-custom-domain-https.md
@@ -17,7 +17,7 @@ ms.custom: devx-track-azurepowershell
 
 # Tutorial: Configure HTTPS on a Front Door (classic) custom domain
 
-This tutorial shows how to enable the HTTPS protocol for a custom domain that's associated with your Front Door (classic) under the frontend hosts section. By using the HTTPS protocol on your custom domain (for example, https:\//www.contoso.com), you ensure that your sensitive data is delivered securely via TLS/SSL encryption when it's sent across the internet. When your web browser is connected to a web site via HTTPS, it validates the web site's security certificate and verifies it's issued by a legitimate certificate authority. This process provides security and protects your web applications from attacks.
+This tutorial shows how to enable the HTTPS protocol for a custom domain that's associated with your Front Door (classic) under the frontend hosts section. By using the HTTPS protocol on your custom domain (for example, `https://www.contoso.com`), you ensure that your sensitive data is delivered securely via TLS/SSL encryption when it's sent across the internet. When your web browser is connected to a web site via HTTPS, it validates the web site's security certificate and verifies it's issued by a legitimate certificate authority. This process provides security and protects your web applications from attacks.
 
 Azure Front Door supports HTTPS on a Front Door default hostname, by default. For example, if you create a Front Door (such as `https://contoso.azurefd.net`), HTTPS is automatically enabled for requests made to `https://contoso.azurefd.net`. However, once you onboard the custom domain 'www.contoso.com' you'll need to additionally enable HTTPS for this frontend host.
 
