Merge pull request #303982 from halkazwini/afd-cert

AFD/CDN managed cert updates

Author: prmerger-automator[bot]

articles/cdn/cdn-custom-ssl.md

@@ -6,10 +6,10 @@ author: halkazwini
 ms.author: halkazwini
 ms.service: azure-cdn
 ms.topic: tutorial
-ms.date: 03/31/2025
+ms.date: 08/07/2025
 ms.custom: mvc
-#Customer intent: As a website owner, I want to enable HTTPS on the custom domain of my CDN endpoint so that my users can use my custom domain to access my content securely.
 ROBOTS: NOINDEX
+
 # Customer intent: As a website owner, I want to configure HTTPS for my custom domain on a CDN endpoint, so that I can ensure the secure delivery of sensitive data to my users.
 ---
 
@@ -54,10 +54,6 @@ Before you can complete the steps in this tutorial, create a CDN profile and at
 
 Associate an Azure CDN custom domain on your CDN endpoint. For more information, see [Tutorial: Add a custom domain to your Azure CDN endpoint](cdn-map-content-to-custom-domain.md).
 
-> [!IMPORTANT]
-> CDN-managed certificates are not available for root or apex domains. If your Azure CDN custom domain is a root or apex domain, you must use the Bring your own certificate feature.
->
-
 ---
 
 ## TLS/SSL certificates
@@ -66,11 +62,13 @@ To enable HTTPS on an Azure CDN custom domain, you use a TLS/SSL certificate. Yo
 
 # [Option 1 (default): Enable HTTPS with a CDN-managed certificate](#tab/option-1-default-enable-https-with-a-cdn-managed-certificate)
 
-Azure CDN handles certificate management tasks such as procurement and renewal. After you enable the feature, the process starts immediately.
+Using a certificate managed by Azure CDN allows you to enable HTTPS with a few settings changes. Azure CDN handles all certificate management tasks, including procurement and renewal. This is supported for custom domains with direct CNAME to Azure CDN endpoint.
 
-If the custom domain is already mapped to the CDN endpoint, no further action is needed. Azure CDN processes the steps and completes your request automatically.
-
-If your custom domain is mapped elsewhere, use email to validate your domain ownership.
+> [!IMPORTANT]
+> - As of May 8, 2025, DigiCert no longer supports the WHOIS-based domain validation method. If your domain uses an indirect CNAME mapping to Azure Front Door Classic endpoint, you must use the **Bring Your Own Certificate (BYOC)** feature.
+> - Due to changes in WHOIS-based domain validation, managed certificates issued using WHOIS-based domain validation can't be autorenewed until you have a direct CNAME pointing to Azure Front Door Classic.
+> - CDN-managed certificates aren't available for root or apex domains. If your Azure CDN custom domain is a root or apex domain, you must use the **Bring Your Own Certificate (BYOC)** feature.
+> - Managed certificate autorenewal requires that your custom domain be directly mapped to your Azure CDN endpoint using a CNAME record.
 
 To enable HTTPS on a custom domain, follow these steps:
 
@@ -143,12 +141,6 @@ Follow the steps in [Configure managed identity for Azure CDN](managed-identity.
 
 ## Validate the domain
 
-If you have a custom domain in use mapped to your custom endpoint with a CNAME record or you're using your own certificate, continue to [Custom domain mapped to your Content Delivery Network endpoint](#custom-domain-is-mapped-to-your-cdn-endpoint-by-a-cname-record).
-
-Otherwise, if the CNAME record entry for your endpoint no longer exists or it contains the cdnverify subdomain, continue to [Custom domain not mapped to your CDN endpoint](#custom-domain-isnt-mapped-to-your-cdn-endpoint).
-
-### Custom domain is mapped to your CDN endpoint by a CNAME record
-
 When you added a custom domain to your endpoint, you created a CNAME record in the DNS domain registrar mapped to your CDN endpoint hostname.
 
 If that CNAME record still exists and doesn't contain the cdnverify subdomain, the DigiCert CA uses it to automatically validate ownership of your custom domain.
@@ -166,44 +158,13 @@ Your CNAME record should be in the following format:
 
 For more information about CNAME records, see [Create the CNAME DNS record](./cdn-map-content-to-custom-domain.md).
 
-If your CNAME record is in the correct format, DigiCert automatically verifies your custom domain name and creates a certificate for your domain. DigitCert doesn't send you a verification email and you don't need to approve your request. The certificate is valid for one year and will be autorenewed before it expires. Continue to [Wait for propagation](#wait-for-propagation).
+If your CNAME record is in the correct format, DigiCert automatically verifies your custom domain name and creates a certificate for your domain. The certificate is valid for one year and will be autorenewed before it expires. Automatic validation typically takes a few hours. If you don't see your domain validated in 24 hours, open a support ticket.
 
-Automatic validation typically takes a few hours. If you don't see your domain validated in 24 hours, open a support ticket.
+Continue to [Wait for propagation](#wait-for-propagation).
 
 >[!NOTE]
 > If you have a Certificate Authority Authorization (CAA) record with your DNS provider, it must include the appropriate CAs for authorization. DigiCert is the CA for Azure CDN profiles. For information about managing CAA records, see [Manage CAA records](https://support.dnsimple.com/articles/manage-caa-record/). For a CAA record tool, see [CAA Record Helper](https://sslmate.com/caa/).
 
-### Custom domain isn't mapped to your CDN endpoint
-
-If the CNAME record entry contains the cdnverify subdomain, follow the rest of the instructions in this step.
-
-DigiCert sends a verification email to the following email addresses. Verify that you can approve directly from one of the following addresses:
-
-- **[email protected]**
-- **[email protected]**
-- **[email protected]**
-- **[email protected]**
-- **[email protected]**
-
-You should receive an email in a few minutes for you to approve the request. In case you're using a spam filter, add [email protected] to its allowlist. If you don't receive an email within 24 hours, contact Microsoft support.
-
-:::image type="content" source="./media/cdn-custom-ssl/domain-validation-email.png" alt-text="Screenshot of the domain validation email.":::
-
-When you select the approval link, you're directed to the following online approval form:
-
-:::image type="content" source="./media/cdn-custom-ssl/domain-validation-form.png" alt-text="Screenshot of the domain validation form.":::
-
-Follow the instructions on the form; you have two verification options:
-
-- You can approve all future orders placed through the same account for the same root domain; for example, contoso.com. This approach is recommended if you plan to add other custom domains for the same root domain.
-
-- You can approve just the specific host name used in this request. Another approval is required for later requests.
-
-After approval, DigiCert completes the certificate creation for your custom domain name. The certificate is valid for one year.  If the CNAME record for your custom domain is added or updated to map to your endpoint hostname after verification, then it will be autorenewed before it's expired.
-
->[!NOTE]
-> Managed certificate autorenewal requires that your custom domain be directly mapped to your CDN endpoint by a CNAME record.
-
 ## Wait for propagation
 
 After the domain name is validated, it can take up to 6-8 hours for the custom domain HTTPS feature to be activated. When the process completes, the custom HTTPS status in the Azure portal is changed to **Enabled**. The four operation steps in the custom domain dialog are marked as complete. Your custom domain is now ready to use HTTPS.

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

@@ -6,7 +6,7 @@ author: halkazwini
 ms.author: halkazwini
 ms.service: azure-frontdoor
 ms.topic: concept-article
-ms.date: 04/09/2025
+ms.date: 08/07/2025
 zone_pivot_groups: front-door-tiers
 ---
 
@@ -33,9 +33,9 @@ Azure Front Door offloads the TLS sessions at the edge and decrypts client reque
 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]
-> As of March 1, 2025, TLS 1.0 and 1.1 are not allowed on new Azure Front Door profiles. 
+> As of March 1, 2025, TLS 1.0 and 1.1 aren't allowed on new Azure Front Door profiles. 
 
-For Azure Front Door Standard and Premium, you can configure predefined TLS policy or choose the TLS cipher suite based on your organization's security needs. For more information, see [Azure Front Door TLS policy](/azure/frontdoor/standard-premium/tls-policy) and [configure TLS policy on a Front oor custom domain](/azure/frontdoor/standard-premium/tls-policy-configure).
+For Azure Front Door Standard and Premium, you can configure predefined TLS policy or choose the TLS cipher suite based on your organization's security needs. For more information, see [Azure Front Door TLS policy](/azure/frontdoor/standard-premium/tls-policy) and [configure TLS policy on a Front Door custom domain](/azure/frontdoor/standard-premium/tls-policy-configure).
 
 For Azure Front Door classic and Microsoft CDN classic, 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. If you want to custom the cipher suite per needs, [migrate Front Door classic](/azure/frontdoor/tier-migration) and [Microsoft CDN classic](/azure/cdn/tier-migration?toc=/azure/frontdoor/TOC.json) to Azure Front Door standard and premium.
 
@@ -58,7 +58,7 @@ OCSP stapling is supported by default in Azure Front Door and no configuration i
 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.my.salesforce-sites.com/microsoft/IncludedCACertificateReportForMSFT). If a certificate without complete chain is presented, the requests which involve that certificate aren't 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 that involve that certificate aren't guaranteed to 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 for resolving 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.
 
@@ -97,7 +97,11 @@ If you choose to use your own certificate, you can onboard a certificate from a
 
 ### Certificate autorotation
 
-For the Azure Front Door managed certificate option, the certificates are managed and auto-rotates within 90 days of expiry time by Azure Front Door. For the Azure Front Door Standard/Premium managed certificate option, the certificates are managed and auto-rotates within 45 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 or 30 days for the Standard/Premium SKU, file a support ticket. 
+For the Azure Front Door Standard/Premium managed certificate option, the certificates are managed and auto-rotates within 45 days of expiry time by Azure Front Door. For the Azure Front Door Classic and Azure CDN Classic managed certificate option, the certificates are managed and auto-rotates within 90 days of expiry time by Azure Front Door.  If you're using classic SKUs managed certificate and see that the certificate expiry date is less than 60 days away or 30 days for the Standard/Premium SKU, file a support ticket. 
+
+> [!IMPORTANT]
+> - For Azure Front Door Classic and Azure CDN Classic, managed certificates will no longer be supported starting August 15, 2025. To avoid service disruption, either switch to **Bring Your Own Certificate (BYOC)** or migrate to Azure Front Door Standard/Premium before this date. Existing managed certificates will continue to autorenew until August 15, 2025, and remain valid until April 14, 2026. However, it's highly recommended to switch to **BYOC** or migrate to Front Door Standard/Premium before August 15, 2025, to avoid unexpected certificate revocation.
+> - Auto-rotation for managed certificates fails if your domains don't have direct CNAME mapping to Azure Front Door Classic or Azure CDN Classic endpoints. See [Azure CDN Classic HTTPS for custom domains](/azure/cdn/cdn-custom-ssl?tabs=option-1-default-enable-https-with-a-cdn-managed-certificate#tlsssl-certificates) and [Azure Front Door Classic HTTPS for custom domains](/azure/frontdoor/front-door-custom-domain-https?tabs=powershell#option-1-default-use-a-certificate-managed-by-front-door).
 
 For your own custom TLS/SSL certificate:
 
@@ -107,7 +111,7 @@ For your own custom TLS/SSL certificate:
 
     > [!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.
-
+ 
     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

articles/frontdoor/front-door-custom-domain-https.md

@@ -5,11 +5,10 @@ author: halkazwini
 ms.author: halkazwini
 ms.service: azure-frontdoor
 ms.topic: how-to
-ms.date: 05/15/2025
+ms.date: 08/07/2025
+ms.custom: build-2025
 
 #Customer intent: As a website owner, I want to enable HTTPS on the custom domain in my Front Door (classic) so that my users can use my custom domain to access their content securely.
-ms.custom:
-  - build-2025
 ---
 
 # Configure HTTPS on an Azure Front Door (classic) custom domain
@@ -75,7 +74,13 @@ To enable HTTPS on a Front Door (classic) custom domain, you need a TLS/SSL cert
 
 ### Option 1 (default): Use a certificate managed by Front Door
 
-Using a certificate managed by Azure Front Door allows you to enable HTTPS with a few settings changes. Azure Front Door handles all certificate management tasks, including procurement and renewal. If your custom domain is already mapped to the Front Door's default frontend host (`{hostname}.azurefd.net`), no further action is required. Otherwise, you must validate your domain ownership via email.
+Using a certificate managed by Azure Front Door Classic allows you to enable HTTPS with a few settings changes. Azure Front Door Classic handles all certificate management tasks, including procurement and renewal. This is supported for custom domains with direct CNAME to Azure Front Door Classic endpoint.
+
+> [!IMPORTANT]
+> - As of May 8, 2025, DigiCert no longer supports the WHOIS-based domain validation method. If your domain uses an indirect CNAME mapping to Azure Front Door Classic endpoint, you must use the **Bring Your Own Certificate (BYOC)** feature.
+> - Due to changes in WHOIS-based domain validation, managed certificates issued using WHOIS-based domain validation can't be autorenewed until you have a direct CNAME pointing to Azure Front Door Classic.
+> - Managed certificates aren't available for root or apex domains (for example, `contoso.com`). If your Azure Front Door Classic custom domain is a root or apex domain, you must use the **Bring Your Own Certificate (BYOC)** feature.
+> - Managed certificate autorenewal requires that your custom domain be directly mapped to your Azure Front Door Classic endpoint using a CNAME record.
 
 To enable HTTPS on a custom domain:
 
@@ -90,7 +95,7 @@ To enable HTTPS on a custom domain:
 1. Proceed to [Validate the domain](#validate-the-domain).
 
 > [!NOTE]
-> - DigiCert’s 64 character limit is enforced for Azure Front Door-managed certificates. Validation will fail if this limit is exceeded.
+> - DigiCert’s 64 character limit is enforced for Azure Front Door-managed certificates. Validation fails if this limit is exceeded.
 > - Enabling HTTPS via Front Door managed certificate isn't supported for apex/root domains (for example, contoso.com). Use your own certificate for this scenario (see Option 2).
 
 ### Option 2: Use your own certificate
@@ -178,13 +183,13 @@ Your CNAME record should be in the following format:
 
 For more information about CNAME records, see [Create the CNAME DNS record](../cdn/cdn-map-content-to-custom-domain.md).
 
-If your CNAME record is correct, DigiCert automatically verifies your custom domain and creates a dedicated certificate. The certificate is valid for one year and autorenews before it expires. Continue to [Wait for propagation](#wait-for-propagation).
+If your CNAME record is in the correct format, DigiCert automatically verifies your custom domain name and creates a certificate for your domain. The certificate is valid for one year and will be autorenewed before it expires. Automatic validation typically takes a few hours. If you don't see your domain validated in 24 hours, open a support ticket.
+
+Continue to [Wait for propagation](#wait-for-propagation).
 
 > [!NOTE]
 > If you have a Certificate Authority Authorization (CAA) record with your DNS provider, it must include DigiCert as a valid CA. For more information, see [Manage CAA records](https://support.dnsimple.com/articles/manage-caa-record/).
 
-> [!IMPORTANT]
-> As of May 8, 2025, DigiCert no longer supports the WHOIS-based domain validation method.
 
 ## Wait for propagation