Merge pull request #177994 from duongau/e2etls

Azure Front Door - End to end TLS new article

Author: laurabren

articles/frontdoor/TOC.yml

@@ -56,6 +56,8 @@
     href: front-door-health-probes.md
   - name: How Front Door matches routing for a request
     href: front-door-route-matching.md
+  - name: End-to-end TLS encryption
+    href: concept-end-to-end-tls.md
   - name: HTTP/2 support
     href: front-door-http2.md
   - name: HTTP headers protocol support

articles/frontdoor/concept-end-to-end-tls.md

@@ -0,0 +1,108 @@
+---
+title: 'End-to-end TLS with Azure Front Door'
+description: Learn about end-to-end TLS encryption when using Azure Front Door.
+services: frontdoor
+author: duongau
+ms.service: frontdoor
+ms.topic: article
+ms.workload: infrastructure-services
+ms.date: 11/02/2021
+ms.author: duau
+---
+
+# 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 browser. This link ensures that all data passed between the web server and the web browser 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's 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.
+
+## 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.
+
+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.
+
+## 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.
+
+## 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](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT). If you use a non-allowed CA, your request will be rejected.
+
+Certificates from internal CAs or self-signed certificates aren't allowed.
+
+## Online Certificate Status Protocol (OCSP) stapling
+
+OSCP stapling is supported by default in Azure Front Door and no configuration is required.
+
+## Backend TLS connection (Azure Front Door to backend)
+
+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.
+
+> [!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, for example, your origin must use a self-signed certificate. As a work-around to resolve failing HTTPS connection, can you disable certificate subject name check for your Azure Front Door. The option to disable is present under the Azure Front Door settings in the Azure portal and on the BackendPoolsSettings in the Azure Front Door API. 
+
+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 managed certificate provides a standard TLS/SSL certificate via DigiCert and is stored in Azure Front Door's Key Vault.   
+
+* 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).
+
+For Azure Front Door managed certificates, the certificates are managed and autorotate within 90 days of expiry time by Azure Front Door. If you're using an Azure Front Door managed certificate and see that the certificate expiry date is less than 60 days away, file a support ticket. 
+
+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 autorotated within 1-2 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.
+
+    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 down time provided the subject name or subject alternate name (SAN) for the certificate didn't changed.
+
+## Supported cipher suites
+
+### For TLS1.2 the following cipher suites are supported:
+
+* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+* TLS_ECDHE_RSA_WITH_AES_128_GCM_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 cipher suites for better security. Windows 8.1, 8, and 7 aren't compatible with these ECDHE cipher suites. The DHE cipher suites have been provided for compatibility with those operating systems.
+
+### Using custom domains with TLS1.0/1.1 enabled the following cipher suites are supported:
+
+* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
+* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
+* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
+* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
+* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
+* TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+* 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
+
+## Next steps
+
+* [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).

articles/frontdoor/front-door-faq.yml

@@ -204,98 +204,8 @@ sections:
         answer: |
           All Front Door profiles created after September 2019 use TLS 1.2 as the default minimum.
           
-          Front Door supports TLS versions 1.0, 1.1 and 1.2. TLS 1.3 is not yet supported.
-          
-      - question: |
-          What certificates are supported on Azure Front Door?
-        answer: |
-          To enable the HTTPS protocol for securely delivering content on a Front Door custom domain, you can choose to use a certificate that is managed by Azure Front Door or use your own certificate.
-          The Front Door managed option provisions a standard TLS/SSL certificate via Digicert and  stored in Front Door's Key Vault. If you choose to use your own certificate, then you can onboard a certificate from a supported CA and can be a standard TLS, extended validation certificate, or even a wildcard certificate. Self-signed certificates are not supported. Learn [how to enable HTTPS for a custom domain](./front-door-custom-domain-https.md).
-          
-      - question: |
-          Does Front Door support autorotation of certificates?
-        answer: |
-          For the Front Door managed certificate option, the certificates are autorotated by Front Door. If you are using a Front Door managed certificate and see that the certificate expiry date is less than 60 days away, file a support ticket.
-          </br>For your own custom TLS/SSL certificate, set the secret version to ‘Latest’ in order for Azure Front Door to automatically rotate to the latest secret version uploaded to your Key Vault. It can take up to 24 hours for the new version of the certificate/secret to be deployed. If you configure the secret version to a specific version, you'll need to point the Front Door to the right certificate version in your Key Vault. Ensure that the service principal for Front Door still has access to the Key Vault. Refer to [how to grant access](standard-premium/how-to-configure-https-custom-domain.md#grant-azure-front-door-access-to-your-key-vault) to your key vault. The updated certificate rollout operation by Front Door won't cause any production down time provided the subject name or subject alternate name (SAN) for the certificate isn't changed.
-          
-      - question: |
-          What are the current cipher suites supported by Azure Front Door?
-        answer: |
-          For TLS1.2 the following cipher suites are supported: 
-          
-          - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-          - TLS_ECDHE_RSA_WITH_AES_128_GCM_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 cipher suites for better security. Windows 8.1, 8, and 7 aren't compatible with these ECDHE cipher suites. The DHE cipher suites have been provided for compatibility with those operating systems.
-          
-          When using custom domains with TLS1.0/1.1 enabled the following cipher suites are supported:
-          
-          - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
-          - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
-          - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-          - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
-          - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
-          - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
-          - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
-          - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
-          - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
-          - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-          - 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
-          
-      - question: |
-          Can I configure TLS policy to control TLS Protocol versions?
-        answer: |
-          You can configure a minimum TLS version in Azure Front Door in the custom domain HTTPS settings via Azure portal or the [Azure REST API](/rest/api/frontdoorservice/frontdoor/frontdoors/createorupdate#minimumtlsversion). Currently, you can choose between 1.0 and 1.2.
-          
-      - question: |
-          Can I configure Front Door to only support specific cipher suites?
-        answer:  |
-          No, configuring Front Door for specific cipher suites is not supported. However, you can get your own custom TLS/SSL certificate from your Certificate Authority (say Verisign, Entrust, or Digicert) and have specific cipher suites marked on the certificate when you have it generated. 
-
-      - question: |
-          Does Front Door support OCSP stapling?
-        answer:  |
-          Yes, OCSP stapling is supported by default by Front Door and no configuration is required.
-
-      - question: |
-          Does Azure Front Door also support re-encryption of traffic to the backend?
-        answer:  |
-          Yes, Azure Front Door supports TLS/SSL offload, and end to end TLS, which re-encrypts the traffic to the backend. In fact, since the connections to the backend happen over its public IP, it is recommended that you configure your Front Door to use HTTPS as the forwarding protocol.
-
-      - question: |
-          Does Front Door support self-signed certificates on the backend for HTTPS connection?
-        answer: |
-          No, self-signed certificates are not supported on Front Door and the restriction applies to both:
-          
-          - **Backends**: You cannot use self-signed certificates when you are forwarding the traffic as HTTPS or HTTPS health probes or filling the cache for from origin for routing rules with caching enabled.
-          - **Frontend**: You cannot use self-signed certificates when using your own custom TLS/SSL certificate for enabling HTTPS on your custom domain.
-          
-      - question: |
-          Why is HTTPS traffic to my backend failing?
-        answer: |
-          For having successful HTTPS connections to your backend whether for health probes or for forwarding requests, there could be two reasons why HTTPS traffic might fail:
-          
-          - **Certificate subject name mismatch**: For HTTPS connections, Front Door expects that your backend presents certificate from a valid 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 neither has `myapp-centralus.contosonews.net` nor `*myapp-centralus*.contosonews.net` in the subject name, the Front Door will refuse the connection and result in an error. 
-              - **Solution**: While it is not recommended from a compliance standpoint, you can workaround this error by disabling certificate subject name check for your Front Door. This is present under Settings in Azure portal and under BackendPoolsSettings in the API.
-          - **Backend hosting certificate from invalid CA**: Only certificates from [valid Certificate Authorities](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT) can be used at the backend with Front Door. Certificates from internal CAs or self-signed certificates aren't allowed. The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT). 
-          
-      - question: |
-          Can I use client/mutual authentication with Azure Front Door?
-        answer: |
-          No. Although Azure Front Door supports TLS 1.2, which introduced client/mutual authentication in [RFC 5246](https://tools.ietf.org/html/rfc5246), currently, Azure Front Door doesn't support client/mutual authentication.
- 
+          Front Door supports TLS versions 1.0, 1.1 and 1.2. TLS 1.3 is not yet supported. Refer to [Azure Front Door end-to-end TLS](concept-end-to-end-tls.md) for more details.
+                  
   - name: Billing
     questions:
       - question: |

articles/frontdoor/front-door-troubleshoot-routing.md

@@ -46,6 +46,22 @@ The cause of this problem can be one of three things:
 
     :::image type="content" source=".\media\troubleshoot-route-issues\remove-encoding-rule.png" alt-text="Screenshot of accept-encoding rule in Rules Engine.":::
 
+## HTTPS traffic to backend fails
+
+### Symptom
+
+HTTPS traffic to backend resource failing.
+
+### Cause
+
+* Certificate with subject name(s) doesn't match the backend hostname during TLS handshake.
+* Backend hosting certificate is not from a valid CA.
+
+### Troubleshooting steps
+
+* While it is not recommended from a compliance standpoint, you can workaround this error by disabling certificate subject name check for your Front Door. This is present under Settings in Azure portal and under BackendPoolsSettings in the API.
+* Only certificates from [valid Certificate Authorities](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT) can be used at the backend with Front Door. Certificates from internal CAs or self-signed certificates aren't allowed. The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the [Microsoft Trusted CA List](https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT).
+
 ## Requests sent to the custom domain return a 400 status code
 
 ### Symptom