azurerm_app_service_managed_certificate: validate domain with TXT DNS rather than CNAME

[bdc]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

1.9.6

AzureRM Provider Version

3.116.0

Affected Resource(s)/Data Source(s)

azurerm_app_service_custom_hostname_binding

Terraform Configuration Files

resource "azurerm_app_service_custom_hostname_binding" "api_server_hostname_binding" {
  resource_group_name = var.resource_group_name
  hostname            = var.api_server_hostname
  app_service_name    = azurerm_linux_web_app.app_service.name
}

Debug Output/Panic Output

Example error message follows (private names are altered):

azurerm_app_service_managed_certificate.api_server_managed_certificate: Creating...                                                     

Error: creating/updating App Service Managed Certificate "mydomain.com" (Resource Group "rg-name"): web.CertificatesClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="BadRequest" Message="Properties.CanonicalName is invalid.  Current CNAME records of the hostname mydomain.com is gateway-subdomain.westus2.cloudapp.azure.com"

Expected Behaviour

Validation should be consistent with the portal behavior: validate the domain via a TXT record instead of CNAME.

---

azurerm_app_service_custom_hostname_binding attaches a custom hostname to an App Service instance. During deployment, the provider checks the hostname's DNS CNAME record to verify that it points to the App Service.

However, the provider should instead check for a TXT record rather than a CNAME. The TXT record proves domain verification, not the CNAME. Checking a TXT record rather than CNAME would match the behavior of the Azure portal.

Why does it matter? Because there exist valid configurations of the App Service and DNS that do not require a CNAME to point directly to it. For example, the Azure docs advise to point the CNAME at a Gateway if using a Gateway. This is possible to configure from the Azure Portal but not from Terraform, which will reject the deployment.

What else? A possible cheap fix would be to allow azurerm_app_service_custom_hostname_binding to skip the CNAME check with a new optional parameter.

Actual Behaviour

Validation fails due to CNAME value different from expected.

Steps to Reproduce

terraform plan -out main.tfplan
terraform apply main.tfplan

Important Factoids

Using ASEv3, Application Gateway, vnet

References

No response

[ziyeqf]

Hi @bdc, thanks for operning the issue.

The validation is done on the service side, we can not skip validation on the provider.

For this specific scenario, I checked the document and it requires a CNAME record. Could you please provide a link to the gateway example?

And per my understanding, if you are pointing the CNAME record to an Application Gateway, it requires to configure the certificate with the Gateway instead of the app service.

For any further questions please leave comments.

[bdc]

Thanks ziyeqf for the quick response.

Here's an example that uses App Service with an Application Gateway.

What's interesting is that App Service only checks the TXT record for validation, not CNAME (although I agree with you - the doc you linked makes it look obligatory!). In practice, I've found the easiest way to deploy this setup is to point the CNAME to App Service, run the deployment, then modify the CNAME to point to the Application Gateway. (While this works alright, it misses out on some of the automation value that terraform/ARM could be providing.)