manage certificate containers error

Question

i have tried many times deleting and recreating manage certficates for container apps enviornment and it keeps failing.

It throws the same client-side CertificateProvisioningError/timeout again with provisioningState: Failed with Operation timed out.

DNS validation is all good and able to validate them successfully but its not creating the certificate successfully. The location is Australia Southeast, Environment Type is Workload profiles, KEDA Version 2.18.1

Answer 1

Hi @Mushaib Yoonus

Based on the three failed attempts for both the apex domain and subdomain in the same new Container Apps environment, this appears less likely to be a problem isolated to one hostname. Successful DNS validation confirms the ownership-record check, but it does not by itself confirm that managed-certificate issuance can complete.

For an interim solution, Azure Container Apps supports binding your own SNI certificate, either uploaded directly or sourced from Azure Key Vault, as described in Custom domain names and bring-your-own certificates in Azure Container Apps.

Before attempting one more issuance, I recommend confirming these shared requirements:

1. HTTP ingress is enabled and the app is publicly reachable from DigiCert validation IP addresses.
2. For the subdomain, the CNAME points directly to the Container App generated FQDN, with no intermediate CNAME, proxy, or traffic-management service.
3. Any CAA record at the domain or an inherited parent domain allows DigiCert; for example, 0 issue digicert.com.
4. The hostname does not fall within a custom environment DNS suffix.

These requirements are documented in Custom domain names and free managed certificates in Azure Container Apps. The documentation indicates that certificate issuance normally takes several minutes after validation succeeds.

If these checks are satisfied, I would avoid further attempts and open an Azure support request for Azure Container Apps. Please include the subscription ID, resource group, Container App and environment resource IDs, both hostnames, Australia Southeast region, UTC timestamps for all failed attempts, the output of az containerapp env certificate list, and the Activity Log operation and correlation IDs. The CLI output shows the certificate resource state, but the failed operation's Activity Log correlation ID is needed to trace the provisioning request.

I would ask support to investigate managed-certificate provisioning at the environment level. The identical failure for both hostname types in a new environment is the relevant evidence for that request. I could not find documentation establishing a relationship between this failure and workload profiles, KEDA 2.18.1, or Australia Southeast, so those should be treated as environment details for support to investigate rather than a confirmed cause.

Please 'Upvote' (Thumbs-up) and 'Accept' as answer if the response was helpful. This will be helpful to other community members who face the same issue.

Best regards, Andrew S Taylor

Answer 2

Hello @Mushaib Yoonus ,

Workaround that always works: Bring your own cert

For production in ASE, I recommend skipping managed certs entirely. Managed certs have had repeated provisioning issues in Australia Southeast.

Create free cert in Key Vault via App Service or Let's Encrypt and bind it:

az containerapp env certificate create -g <rg> -n <env> \

--certificate <kv-cert-id> \

--akv-url <keyvault-cert-url> \

--identity <managed-identity-id>

This never hits the CertificateProvisioningError.

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.