The managed certificate flow is failing because the validation logic is explicitly requiring an A record that points directly to the app’s IP, even though CNAME is generally supported for custom domains. This behavior matches the documented requirement for certain certificate scenarios: for free managed certificates and apex-domain certificates, an A record must exist and point to the web app IP, and CNAME-only configurations are not sufficient for HTTP-based validation.

From the context:

• For root domains, an A record plus TXT is required; for subdomains, CNAME is preferred for domain mapping, but the managed certificate renewal/validation path still has stricter rules in some cases.
• The free managed certificate and apex domain certificate require the A record to point to the web app's IP address and the subdomain CNAME to point to <app-name>.azurewebsites.net. If these conditions are not met, certificate issuance/renewal is blocked.
• The error in the diagnostic log (CheckARecordForHttp / “A record not found”) is consistent with this requirement.

Given the behavior and the available documentation, the practical resolution is:

1. Ensure DNS is configured in the pattern required for managed certificates:
   • For the hostname being secured, create an A record pointing directly to the web app’s IP address (from the App Service “Custom domains” blade or az webapp config hostname list).
   • For subdomains, keep or add the CNAME pointing to <app-name>.azurewebsites.net if needed for other scenarios, but do not have both A and CNAME for the same name; choose one per hostname as required.
   • Ensure the TXT verification record (for domain ownership) is present and correct where required (for root domains, TXT at @; for subdomains, asuid.<subdomain>), as described in the custom domain and certificate troubleshooting guidance.
2. Avoid conflicting records:
   • Do not configure both an A record and a CNAME record for the same hostname, as this causes resolution conflicts and can prevent Azure from validating the domain and issuing the certificate.
3. After DNS is corrected:
   • Wait for DNS propagation (up to 48 hours in worst case, but typically much less).
   • Use global DNS tools to confirm that the hostname resolves either via A record directly to the app IP (for the managed certificate requirement) or via the documented A+TXT/CNAME patterns.
   • Retry the managed certificate creation from the App Service TLS/SSL settings.

If the hostname must remain CNAME-only and cannot have an A record pointing to the app IP, the built-in managed certificate mechanism may not complete HTTP validation for that specific configuration. In that case, the alternative is to use a different certificate option (for example, an App Service certificate or an external certificate uploaded as PFX) and bind it manually, following the documented certificate lifecycle (Buy/Store/Verify/Import/Bind).

References:

• Troubleshoot custom domain issues in Azure App Service for web apps on Windows and Linux
• Troubleshoot domain and TLS/SSL certificate problems in Azure App Service
• Tutorial: Use a custom domain and a managed certificate to secure your app
• Troubleshoot Azure App Service certificates