Acrolinx

johndowns · johndowns · commit f34a9fc2c623 · 2023-02-07T15:38:15.000+13:00
diff --git a/articles/frontdoor/apex-domain.md b/articles/frontdoor/apex-domain.md
@@ -22,7 +22,7 @@ To add a root or apex domain to your Azure Front Door profile, see [Onboard a ro
 
 The DNS protocol prevents the assignment of CNAME records at the zone apex. For example, if your domain is `contoso.com`, you can create a CNAME record for `myappliation.contoso.com`, but you can't create a CNAME record for `contoso.com` itself.
 
-Azure Front Door doesn't expose the frontend public IP address associated with your Azure Front Door endpoint. This means that you can't map an apex domain to an IP address if your intent is to onboard it to Azure Front Door. 
+Azure Front Door doesn't expose the frontend public IP address associated with your Azure Front Door endpoint. So, you can't map an apex domain to an Azure Front Door IP address.
 
 > [!WARNING]
 > Don't create an A record with the public IP address of your Azure Front Door endpoint. Your Azure Front Door endpoint's public IP address might change and we don't provide any guarantees that it will remain the same.
@@ -36,7 +36,7 @@ Mapping your apex or root domain to your Azure Front Door profile uses *CNAME fl
 
 ## TXT record validation
 
-To validate a domain, you need to create a DNS TXT record. The name of the TXT record 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.
+To validate a domain, you need to 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 apex domain `contoso.com` with Azure Front Door. First, you should add the domain to your Azure Front Door profile, and note the TXT record value that you need to use. Then, you should configure a DNS record with the following properties:
 
diff --git a/articles/frontdoor/domain.md b/articles/frontdoor/domain.md
@@ -24,9 +24,9 @@ To learn how to add a custom domain to your Azure Front Door profile, see [Confi
 
 ## DNS configuration
 
-When you add a domain to your Azure Front Door profile, you typically need to configure two records in your DNS server:
+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 usually required to validate ownership of your domain name. For more information on the DNS TXT records, see [Domain validation](#domain-validation).
+* 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](#domain-validation).
 * A DNS CNAME record, which controls the flow of internet traffic to Azure Front Door.
 
 > [!TIP]
@@ -47,7 +47,7 @@ All domains added to Azure Front Door must be validated. Validation helps to pro
 
 ### TXT record validation
 
-To validate a domain, you need to create a DNS TXT record. The name of the TXT record 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.
+To validate a domain, you need to 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, you should add the domain to your Azure Front Door profile, and note the TXT record value that you need to use. Then, you should configure a DNS record with the following properties:
 
@@ -67,7 +67,7 @@ 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. <br /><br /> Please wait until the domain resource is ready. |
+| Submitting | The custom domain is being created. <br /><br /> Wait until the domain resource is ready. |
 | Pending | The DNS TXT record value has been generated, and Azure Front Door is ready for you to add the DNS TXT record. <br /><br /> 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 has been updated with the DNS provider, select **Regenerate** to refresh the TXT record then add the TXT record to your DNS provider again. |
 | Pending re-validation | The managed certificate is less than 45 days from expiring. <br /><br /> 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 is pointed 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 will change to **Pending**. <br /> No action is required. |
@@ -161,7 +161,8 @@ For a guided walkthrough of these steps, see [Configure HTTPS on an Azure Front
 You can change a domain between using an Azure Front Door-managed certificate and a user-managed certificate.
 
 * It might take up to an hour for the new certificate to be deployed when you switch between certificate types.
-* If your domain state is *Approved*, switching the certificate type between a user-managed and a managed certificate won't cause any downtime. When switching to a managed certificate, unless the domain ownership is re-validated and the domain state becomes *Approved*, you will continue to be served by the previous certificate.
+* If your domain state is *Approved*, switching the certificate type between a user-managed and a managed certificate won't cause any downtime.
+* When switching to a managed certificate, Azure Front Door continues to use the previous certificate until the domain ownership is re-validated and the domain state becomes *Approved*.
 * If you switch from BYOC to managed certificate, domain re-validation is required. If you switch from managed certificate to BYOC, you're not required to re-validate the domain.
 
 ### Certificate renewal
@@ -182,7 +183,7 @@ If one of the scenarios above applies to your custom domain, then 45 days before
 > [!NOTE]
 > DNS TXT records expire after seven days. If you previously added a domain validation TXT record to your DNS server, you need to replace it with a new TXT record. Ensure you use the new value, otherwise the domain validation process will fail.
 
-If your domain can't be validated, the domain validastion state becomes *Rejected*. This state indicates that the certificate authority has rejected the request for reissuing a managed certificate.
+If your domain can't be validated, the domain validation state becomes *Rejected*. This state indicates that the certificate authority has rejected the request for reissuing a managed certificate.
 
 For more information on the domain validation states, see [Domain validation states](#domain-validation-states).
 
@@ -192,7 +193,11 @@ Azure-managed certificates are automatically rotated by the Azure service that v
 
 #### <a name="rotate-own-certificate"></a>Renew customer-managed TLS certificates
 
-In order for the certificate to automatically be rotated to the latest version when a newer version of the certificate is available in your key vault, set the secret version to 'Latest'. If a specific version is selected, you have to reselect the new version manually for certificate rotation. It takes up to 72 hours for the new version of the certificate/secret to be automatically deployed.
+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 have to reselect the new version manually when you update your certificate.
+
+It takes up to 72 hours for the new version of the certificate/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. 
 
diff --git a/articles/frontdoor/end-to-end-tls.md b/articles/frontdoor/end-to-end-tls.md
@@ -64,7 +64,7 @@ In Azure Front Door Standard and Premium, you can configure an origin to disable
 
 ::: 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.
+In Azure Front Door (classic), you can 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
 
@@ -99,7 +99,7 @@ For your own custom TLS/SSL certificate:
 
 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.
+    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.
 
 ## Supported cipher suites
 
diff --git a/articles/frontdoor/front-door-custom-domain-https.md b/articles/frontdoor/front-door-custom-domain-https.md
@@ -70,7 +70,7 @@ To enable HTTPS on a custom domain, follow these steps:
 
 ### Option 2: Use your own certificate
 
-You can use your own certificate to enable the HTTPS feature. This process is done through an integration with Azure Key Vault, which allows you to store your certificates securely. Azure Front Door uses this secure mechanism to get your certificate and it requires a few extra steps. 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.  If a certificate without complete chain is presented, the requests which involve that certificate are not guaranteed to work as expected.
+You can use your own certificate to enable the HTTPS feature. This process is done through an integration with Azure Key Vault, which allows you to store your certificates securely. Azure Front Door uses this secure mechanism to get your certificate and it requires a few extra steps. 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.  If a certificate without complete chain is presented, the requests that involve that certificate are not guaranteed to work as expected.
 
 #### Prepare your key vault and certificate
 
diff --git a/articles/frontdoor/front-door-how-to-onboard-apex-domain.md b/articles/frontdoor/front-door-how-to-onboard-apex-domain.md
@@ -63,7 +63,7 @@ You can use the Azure portal to onboard an apex domain on your Azure Front Door
 
     - If you're using another DNS provider, manually create a new TXT record of name `_dnsauth.<your_subdomain>` with the record value as shown on the page.
 
-1. Close the *Validate the custom domain* page and return to the *Domains* page for the Front Door profile. You should see the *Validation state* change from **Pending** to **Approved**. If not, wait up to 10 minutes for changes to reflect. If your validation doesn't get approved make sure your TXT record is correct and name servers are configured correctly if you're using Azure DNS.
+1. Close the *Validate the custom domain* page and return to the *Domains* page for the Front Door profile. You should see the *Validation state* change from **Pending** to **Approved**. If not, wait up to 10 minutes for changes to reflect. If your validation doesn't get approved, make sure your TXT record is correct and name servers are configured correctly if you're using Azure DNS.
 
     :::image type="content" source="./media/front-door-apex-domain/validation-approved.png" alt-text="Screenshot of new custom domain passing validation.":::
 
diff --git a/articles/frontdoor/standard-premium/how-to-add-custom-domain.md b/articles/frontdoor/standard-premium/how-to-add-custom-domain.md
@@ -71,7 +71,7 @@ A custom domain is configured on the **Domains** page of the Azure Front Door pr
 
     :::image type="content" source="../media/how-to-add-custom-domain/provisioned-approved-status.png" alt-text="Screenshot of provisioned and approved status.":::
 
-For more infromation about domain validation states, see [Domains in Azure Front Door](../domain.md#domain-validation).
+For more information about domain validation states, see [Domains in Azure Front Door](../domain.md#domain-validation).
 
 ## Associate the custom domain with your Azure Front Door endpoint
 
