Managed certificate stuck in Pending for apex domain in Azure Container Apps Environment

Question

Hi,

I have an issue with creating a managed certificate for an apex domain (like example.com) in my Azure Container Apps Environment. The new certificate is stuck in Pending state.

I have setup all dns records (A, TXT asuid, and CAA issue "digicert.com") and a custom hostnam for the app.

What I have verified is

• A record points to the Container Apps Environment static IP.
• TXT asuid exists and matches container app verification ID.
• CAA record includes 0 issue "digicert.com".
• az containerapp show command tells the apex hostname under ingress.customDomains is "bindingType": "Disabled".
• HTTP to the contianer app without SSL works.

Other certs for subdomains in the same environment succeed. It is only the apex cert is stuck Pending.

Can anyone guide me in the right direction or give me hints of where to get more logs about the certificate issuance procedure.

Thanks!

Answer 1

dear Mattias hi,

this usually happens because managed cert issuance for apex domains in azure container apps is more sensitive than for subdomains and it depends not only on dns correctness but also on hostname binding state and http validation reachability.

if ingress.customDomains shows bindingType disabled it means the custom domain is not fully bound yet at the environment level and certificate validation will not proceed even if the dns records look correct. first make sure the apex domain is properly added and validated at the container app level and not only at the environment static ip level.

Managed certificates in aca rely on http validation via digicert so the apex domain must resolve publicly to the environment static ip and port 80 must be reachable from the internet without redirect loops or firewall restrictions. even if http works from ur browser it must return a valid response for the validation path used during issuance. also double check that there is no existing conflicting ssl binding at the environment or app level because stale bindings can keep the cert in pending state. Since subdomains work it confirms the environment is fine and the issue is specific to apex validation flow.

if everything looks correct try removing the apex custom domain completely then re add it and recreate the managed certificate because sometimes the initial validation token does not refresh properly. unfortunately aca does not expose detailed digicert issuance logs so activity log and diagnostic logs at the container apps environment level are the only place to check for backend errors. in most cases apex pending issues are caused by incomplete hostname binding or http validation not being fully reachable even though dns looks correct.

rgds,

Alex

Answer 2

Hi @Mattias ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The "Pending" state for a managed certificate on an apex domain (e.g., example.com) typically indicates that the Domain Control Validation (DCV) check is failing or stuck. Since you have already verified the DNS records (A, TXT, CAA), the issue is likely related to network accessibility or conflicting CAA records.

Below are the troubleshooting steps to resolve the issue. Please try below steps and share your findings.

1. Verify HTTP (Port 80) Accessibility For the managed certificate issuer (DigiCert) to validate your domain, your Container App must be publicly accessible on Port 80.
   • Why: Azure uses an HTTP-01 challenge for validation. The validator sends a request to http://example.com/.well-known/pki-validation/....
   • Check:
     • Ensure your Container App Ingress is set to "Accept traffic from anywhere" (not limited to VNET or specific IPs).
     • If you are using an NSG (Network Security Group) on the subnet delegated to the Container Apps Environment, ensure it allows Inbound TCP traffic on Port 80 from the internet (Service Tag: Internet).
     • Crucial: Even if you plan to use HTTPS only, do not force a redirect from HTTP to HTTPS in your application code or ingress configuration during the validation phase. The validator might fail if it receives a 301/302 redirect to an HTTPS endpoint that doesn't have a valid cert yet.
2. Check for Conflicting CAA Records You mentioned you added 0 issue "digicert.com". However, if there are other CAA records present (e.g., from a previous provider or default registrar settings), they can block the issuance.
   • Action: Run dig example.com CAA
   • Rule: If any CAA records exist, only the CAs listed are allowed to issue. Ensure no other issue records exist that conflict or restrict issuance to other providers (like Let's Encrypt) without also including DigiCert.
3. Cleanup and Retry (The "Stuck" State) If the certificate has been "Pending" for more than a few hours, it is likely stuck in a failed state internally and will not recover on its own.
   1. Delete the pending certificate from the "Certificates" blade.
   2. Delete the custom domain binding from the "Custom domains" blade.
   3. Wait 15-30 minutes for the backend state to clear.
   4. Re-add the Custom Domain first.
   5. Re-create the Managed Certificate.
4. Verify the asuid TXT Record Name For an apex domain, the TXT record host should be exactly asuid (resulting in asuid.example.com).
   • Common Mistake: Sometimes DNS providers append the domain name automatically. Ensure you didn't accidentally create asuid.example.com.example.com.
   • Verification: Run dig asuid.example.com TXT and confirm it returns only the verification ID.
5. Check "Hidden" Error Messages via CLI Use the Azure CLI to check the detailed status:

      az containerapp env certificate list --resource-group <resource-group> --name <env-name> --output json
   

   Look for the provisioningState and any error details in the JSON output. It may reveal a specific error like "CAA record prevents issuance" or "Domain ownership validation failed". Note on bindingType: The bindingType: "Disabled" status you see is normal. You cannot switch this to SniEnabled until the certificate status changes from Pending to Succeeded.

Note: The response was generated with the help of an AI system.