App Service Managed Certificate creation fails when adding SSL binding - "Hostname not eligible" despite correct CNAME and passing Azure DNS diagnostics

Hi Jake,

Several other people are experiencing same issue as you in West US 2 (unsure if it is only that region). For immediate term, I recommend you obtain free certificate from Let's Encrypt (or purchase cheap cert) and upload it to your App Service. That way everything will work fine while the underlying issue gets worked out.

After you get your site working with a non-managed certificate you can periodically try creating Managed Certificate and when it succeeds you can decide to switch over if you want. That way you can avoid downtime.

If you need help with obtaining free or purchased certificate I can assist.

NOTE: Currently there is no ETA or acknowledgement of the issue.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

App Service Managed Certificates (ASMC) are more restrictive than basic custom-domain validation and can fail even when DNS diagnostics and hostname validation pass.

From the documented behavior and common issues, the following points are relevant to this scenario:

1. Prerequisites and supportability

• The App Service plan must be Basic (B1) or higher. That requirement is already met (Linux B1).
• The custom domain must be fully validated and mapped to the app before ASMC can be created. If the domain shows as added with a green checkmark but No binding, that is the expected state right before creating an ASMC.
• ASMC does not support wildcard certificates. The hostname must be a specific FQDN (for example, www.contoso.com), not *.contoso.com.

2. DNS configuration requirements The documented, supported patterns are:

• For subdomains (for example, www.contoso.com):
  • Use a CNAME record pointing to <appname>.azurewebsites.net.
  • Optionally, use a TXT record with the asuid.<subdomain> prefix for verification.
• For root/apex domains (for example, contoso.com):
  • Use an A record pointing to the app’s IP, plus a TXT record for verification.
• Never configure both a CNAME and an A record for the same hostname; this can cause resolution conflicts and make certificate behavior appear inconsistent even if basic validation passes.

Given the steps already tried, the recommended stable configuration for a subdomain that should work with ASMC is:

1. In the DNS provider:
   • Ensure only a CNAME exists for the subdomain (for example, sub.example.com → <appname>.azurewebsites.net).
   • Ensure the TXT record asuid.sub (or equivalent) is present and matches the Custom Domain Verification ID.
   • Remove any A record for that exact subdomain name.
2. In the Azure portal for the App Service:
   • Confirm the custom domain appears with a green checkmark and status No binding.
   • From Custom domains, select the hostname, choose Add binding, and select App Service Managed Certificate.
3. Known limitations and conflicts The following documented issues can cause SSL/ASMC problems even when DNS looks correct:

• Mixed or conflicting DNS records (A + CNAME for the same name).
• Misconfigured or conflicting SSL binding types (IP-based vs SNI) on the same app or plan. For ASMC, use SNI SSL, and avoid multiple IP-based bindings on the same IP.
• Attempting to use ASMC for scenarios it does not support (for example, wildcards, cross-subscription use of certificates, or domains not actually resolving to the app because of DNS misconfiguration).

4. When the platform state is stuck The context includes examples where Azure resources or platform operations get stuck or behave inconsistently and later resolve only after some time or after reconfiguration. For DNS-related custom domain issues, the supported recovery pattern is:

• Remove the custom domain from the App Service.
• Clean up DNS so that only the recommended records exist (CNAME for subdomain, A+TXT for root, but not both for the same name).
• Re-add the custom domain and validate again.
• Then configure SSL (ASMC or custom certificate) and bindings.

If, after ensuring:

• The hostname is a specific FQDN (not a wildcard),
• DNS uses only a CNAME for that subdomain pointing to <appname>.azurewebsites.net,
• The TXT asuid.<subdomain> record is correct,
• The domain is validated and mapped to the app,
• The binding is created as SNI SSL,

the ASMC creation still fails with “Hostname not eligible,” the documented next step is to open an Azure support ticket so the domain and certificate provisioning state can be corrected manually. The custom-domain troubleshooting guidance explicitly notes that in cases where internal state or prior mappings block correct behavior, support intervention is required to release or fix the hostname.

Because Basic support does not include technical support tickets, a practical workaround is to avoid ASMC and instead:

• Use a custom certificate (for example, from an external CA or via another automation mechanism),
• Upload it as a PFX to the App Service,
• Then create a standard SNI SSL binding for that hostname.

This bypasses the ASMC-specific eligibility checks while still providing HTTPS for the custom domain.

References:

• Troubleshoot custom domain issues in Azure App Service for web apps on Windows and Linux
• Troubleshoot Azure App Service certificates
• Set up an existing custom domain in Azure App Service