manage certificate containers error

Hi @Mushaib Yoonus

Thank you for your time, patience, and collaboration throughout this investigation.

When this case was opened, the issue was related to the Container Apps environment in Australia Southeast, where Managed Certificates and associated Container Apps resources were not functioning as expected. Throughout the engagement, we worked closely with the Product Group and engineering teams to investigate the behavior of the environment, including Container Apps provisioning, managed certificate functionality, environment state, managed identity authentication, and Azure Container Registry (ACR) interactions.

Multiple findings and recovery paths were analyzed during the investigation. Engineering teams reviewed platform telemetry, evaluated Container Apps reconciliation behavior, investigated managed identity and ACR authentication flows, and provided recommended validation and recovery options to help isolate the issue observed in the original environment.

To mitigate the impact, you successfully deployed a parallel Container Apps environment in Australia East and confirmed that Managed Certificates were provisioned successfully and that the environment is operating as expected.

You have confirmed that:

• The Australia East environment is functioning successfully.
• Managed Certificates are working as expected in the new environment.
• Business impact has been mitigated through the new environment.
• You have elected to continue using the Australia East environment.
• You plan to decommission the Australia Southeast environment.
• You have confirmed that the support request can be closed.

Regarding your question in our private chat about billing or service credit considerations, these requests are handled by the Azure Billing Support team and can be raised through:

Azure Portal → Help + Support → Create a Support Request → Issue Type: Billing

We sincerely appreciate your patience, cooperation, and partnership while we worked through this investigation.

Thanks for your positive response, If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Thank you!

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

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.