Managed certificated was not rotated automatically

Hi @avenuce Thank you for reaching out to Microsoft Q&A.

Can you try re-creating the managed certificate? It failed, because it was not able to renew the certificate in the specific window. Re-creating the managed certificate will start the fresh create operation.

Also, Can you provide me the details, I have asked in the private chat?

How long to wait?

Hi @avenuce

The error “There’s a managed certificate for this domain that is pending issuance. You cannot create another managed certificate for this domain” occurs because Azure allows only one active managed certificate issuance process per custom domain at a time. When a managed certificate creation or renewal is triggered, Azure marks it as Pending issuance and places a backend lock on that domain. While this state exists, Azure blocks any attempt to create another managed certificate for the same hostname. If the pending issuance gets stuck (for example, due to DNS validation failure, CA validation delay, or a backend service issue), the lock is not released automatically, which prevents further certificate creation until the pending operation is resolved or cleaned up.

Refer below points to resolve this issue or this is the workaround:

Wait for the pending issuance to complete or fail If the certificate is genuinely still being issued, Azure will eventually move it to Succeeded or Failed. Once the state changes, the domain lock is released, and you can proceed accordingly.

Delete the stuck pending managed certificate If the certificate remains in Pending issuance for an extended time and does not progress, delete the managed certificate entry from the portal. This clears the backend lock and allows you to create a new managed certificate for the domain.

Ensure DNS validation is correct before recreating the certificate Verify that:

• The CNAME/A record points directly to the expected Azure endpoint
• There are no CNAME chains or intermediaries
• No CAA record is blocking DigiCert Incorrect DNS is the most common reason certificates remain stuck in Pending issuance.

Avoid repeated create attempts while pending Retrying certificate creation while the status is Pending issuance will always fail with this error. Azure does not queue or override existing issuance attempts.

Use Azure Key Vault–based certificates as a long‑term workaround For production‑critical domains, store the certificate in Azure Key Vault, enable auto‑rotation, and bind the service to the Key Vault certificate. This avoids domain‑level locks and managed certificate issuance delays entirely.

So, I deleted certificate from azure container app environment. Clicked to create new one. It's pending more than 1 hour. I enabled system assigned managed identity. Added RBAC Key Vault Secrets Users (and also access policy certificates get,list,import) for system assigned identity on key vault with my certificates. I'm trying to import certificate but facing error 'system' doesn't have permissions to key vault certificate.
What else can I try with my production?
How long to wait for managed certificate creation which is in pending state?

Hi @avenuce

What you are observing is a combination of expected Azure Container Apps managed certificate behavior and a Key Vault permission / identity mismatch. In Azure Container Apps, managed certificate creation is a backend, asynchronous process. If the certificate stays in Pending state for an extended period, it usually indicates that domain validation or backend issuance has not completed yet. At the same time, importing a certificate from Azure Key Vault requires the Container Apps environment‑level managed identity to have correct Key Vault data‑plane permissions. Even if permissions look correct, a mismatch between RBAC vs access policies or using the wrong identity (system vs user‑assigned) can cause the error stating that “system doesn’t have permissions to Key Vault certificate”. This is a known and documented limitation with Container Apps and managed identities.

Refer below points to resolve this issue or this is the workaround:

Understand how long to wait for managed certificate creation (Pending state) For Azure Container Apps managed certificates, the creation is asynchronous and depends on CA issuance and domain validation. Microsoft documentation and field experience indicate that issuance can take up to ~45–60 minutes in normal conditions. If the certificate remains in Pending beyond this window and does not move to Succeeded or Failed, it usually means validation is stuck and it will not self‑heal. In that case, deleting and recreating the managed certificate is the only supported action.

Ensure you are granting permissions to the Container Apps environment identity (not the app identity) Certificate import from Key Vault in Container Apps is performed by the environment‑level managed identity, not by the individual container app. Even if the app has identity enabled, the import will fail if the environment identity does not have access. This is explicitly documented for Container Apps certificate management.

Use Azure RBAC only (do not mix RBAC and access policies) If your Key Vault is using Azure RBAC, adding legacy access policies (get/list/import) will not be honored. In RBAC mode, you must assign:

• Key Vault Secrets User (required)
• Key Vault Certificate User (required for certificate import)

Both roles must be assigned at the Key Vault scope to the Container Apps environment managed identity. Mixing RBAC and access policies is a common cause of the “system doesn’t have permissions” error.

Prefer a user‑assigned managed identity (strongly recommended for production) There is a known limitation where system‑assigned identities may not be fully resolvable during certificate or secret validation flows. Using a user‑assigned managed identity avoids this race condition because the identity exists before the operation starts. Microsoft guidance and community reports confirm this as a reliable workaround.

Steps:

1. Create a user‑assigned managed identity.
2. Assign Key Vault Secrets User and Key Vault Certificate User roles to this identity at the Key Vault scope.
3. Attach the user‑assigned identity to the Container Apps environment.
4. Import the certificate from Key Vault using this identity.