[Enhancement:] azurerm_cdn_frontdoor_custom_domain - validate host_name values, refine ManagedCertificate hostname constraints, and harden related Front Door acceptance tests

[WodansSon]

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

This PR updates validation and related test coverage for azurerm_cdn_frontdoor_custom_domain, including managed-certificate-specific hostname constraints, wildcard-domain handling, refreshed documentation for current Azure Front Door behavior, and adjacent CDN acceptance test fixes needed to keep the suite aligned with current deprecation rules.

The Provider Changes Are:

• Add provider-side validation for host_name so it must be a valid fully qualified domain name
• Add managed-certificate-specific diff validation so tls.certificate_type = "ManagedCertificate" rejects host_name values longer than 64 characters
• Preserve the existing customized cipher suite validation behavior alongside the managed certificate validation
• Restrict the accepted custom TLS 1.2 cipher suites to the ECDHE values that the Front Door service actually supports
• The Front Door service team confirmed the supported TLS 1.2 cipher set excludes the DHE suites returned by the SDK helper, and they also confirmed the Learn documentation has been queued for update to match
• Keep wildcard domains valid for host_name validation generally, while rejecting wildcard domains specifically when tls.certificate_type = "ManagedCertificate"

The Test Changes Are:

• Add local unit coverage for the new host_name validator
• Add targeted acceptance coverage for the managed certificate validation path using ExpectError
• Shorten managed-certificate host labels in the affected Front Door acceptance helpers so generated host names stay within the service limit
• Replace the delegated child-zone suffix generation in the affected Front Door acceptance helpers with data.RandomString to reduce collisions between tests started close together
• Omit apex-domain managed certificate acceptance coverage for now, and document that limitation inline in the acceptance test file until a dedicated reviewer-approved approach is agreed
• Fix existing CDN acceptance/data source tests that still create deprecated CDN resources, so they respect the current long-tail creation deprecation behavior and skip cleanly instead of failing at plan time
• Add unit coverage for wildcard-domain host_name validation and keep managed-certificate wildcard rejection covered in acceptance validation
• Document that positive wildcard-domain coverage with CustomerCertificate is deferred until a reusable customer-certificate test fixture is available

The Documentation Changes Are:

• Document the managed certificate hostname limits for azurerm_cdn_frontdoor_custom_domain
• Document that Azure Front Door supports managed certificates for apex domains, but apex-domain certificate rotation can require domain revalidation
• Keep the nested tls argument ordering aligned with the docs contract

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them.
• I have written new tests for my resource or datasource changes & updated any relevant documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide.
• The tests pass locally for all relevant acceptance coverage.

Note

Apex-domain managed certificate acceptance test coverage is intentionally not included in this PR. Azure Front Door now supports managed certificates for apex domains, and the provider/docs changes here align with that behavior. However, the current Front Door acceptance fixture reuses a shared DNS parent-domain setup across tests, and I did not want to mutate that shared setup without agreement on a dedicated approach from the reviewer who owns the domain. I left an inline note in cdn_frontdoor_custom_domain_resource_test.go so this limitation is documented in the code as well.

Change Log

• azurerm_cdn_frontdoor_custom_domain - validate host_name values, refine ManagedCertificate hostname constraints, and harden related Front Door acceptance tests

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

N/A

AI Assistance Disclosure

• AI Assisted - This contribution was made by, or with the assistance of, AI/LLMs

Extent of AI usage:

• Initial code, test, and documentation drafting
• Static review of local changes
• Iteration on wording and acceptance test helper changes

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the provider.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

No changes to security controls.