App Service Managed Certificate expires while pending; retry remains Accepted and certificate list is empty

Hello Petr Vambera ,

Greetings! Thanks for raising this question in the Q&A forum.

The error "Pending certificate expired" means App Service Managed Certificate (ASMC) issuance started, but the DigiCert domain validation did not complete before the pending request timed out. Since all your DNS, CAA, and SKU checks pass, the most likely causes are a validation request that cannot reach the app endpoint, or a stale pending issuance record that keeps blocking new attempts (which fits the "duplicate certificate ... available or in pending issued" error). Your second request at 10:44 was also started before the first one expired at 10:47, so the two attempts may have overlapped.

Let the current pending request finish before trying again. Do not submit more create requests while one shows only Started and Accepted. Each new request can hit the duplicate error and restart the clock. Pending requests normally end with a terminal result after a couple of hours, so wait for the 10:44 request to either succeed or fail.

Check that the validation token endpoint works. Since July 2025 ASMC uses HTTP token validation. DigiCert requests https://<hostname>/.well-known/pki-validation/fileauth.txt, and App Service places the token there during issuance. While a request is pending, test it from outside Azure:

curl -vk https://<your-subdomain>/.well-known/pki-validation/fileauth.txt

The hostname must resolve publicly and reach the App Service front end directly. Make sure there is no proxy in front such as a Cloudflare orange cloud proxy, Azure Front Door, Application Gateway, or Traffic Manager, and make sure the CNAME points straight to <app>.azurewebsites.net with no extra hops that rewrite or redirect the path. Microsoft's November 2025 update says restrictions like IP rules, private endpoints, and client certificates are generally handled, but a public DNS record is still required.

Hello Petr Vambera,

Greetings! Thanks for raising this question in the Q&A forum.

The error "Pending certificate expired" means App Service Managed Certificate (ASMC) issuance started, but the DigiCert domain validation did not complete before the pending request timed out. Since all your DNS, CAA, and SKU checks pass, the most likely causes are a validation request that cannot reach the app endpoint, or a stale pending issuance record that keeps blocking new attempts (which fits the "duplicate certificate ... available or in pending issued" error). Your second request at 10:44 was also started before the first one expired at 10:47, so the two attempts may have overlapped.

Let the current pending request finish before trying again. Do not submit more create requests while one shows only Started and Accepted. Each new request can hit the duplicate error and restart the clock. Pending requests normally end with a terminal result after a couple of hours, so wait for the 10:44 request to either succeed or fail.

Check that the validation token endpoint works. Since July 2025 ASMC uses HTTP token validation. DigiCert requests https://<hostname>/.well-known/pki-validation/fileauth.txt, and App Service places the token there during issuance. While a request is pending, test it from outside Azure:

curl -vk https://<your-subdomain>/.well-known/pki-validation/fileauth.txt

The hostname must resolve publicly and reach the App Service front end directly. Make sure there is no proxy in front such as a Cloudflare orange cloud proxy, Azure Front Door, Application Gateway, or Traffic Manager, and make sure the CNAME points straight to <app>.azurewebsites.net with no extra hops that rewrite or redirect the path. Microsoft's November 2025 update says restrictions like IP rules, private endpoints, and client certificates are generally handled, but a public DNS record is still required.

1. Look for hidden or stale certificate resources. The portal list can be empty even when a pending object exists. Query the resource provider directly:

az resource list --resource-type Microsoft.Web/certificates --query "[].{name:name, rg:resourceGroup, domain:properties.canonicalName, state:properties.provisioningState}" -o table

Also check the resource group of the App Service plan, since certificates are stored with the plan's resource group. If you find a failed or orphaned certificate for your hostname, remove it:

az resource delete --ids <certificate-resource-id>

1. Retry with the CLI after the pending request has ended. This also gives a clearer error message than the portal:

az webapp config ssl create --resource-group <rg> --name <app-name> --hostname <your-subdomain>
az webapp config ssl bind --resource-group <rg> --name <app-name> --certificate-thumbprint <thumbprint> --ssl-type SNI

Check the other usual blockers once more: the app must be running, the plan must be Basic or higher, and the hostname must already be added as a custom domain on the app. Also check CAA records on parent domains, since a CAA record on the root domain applies to the subdomain.

1. Use a temporary alternative if you need HTTPS now. You can upload any certificate as a PFX (for example from your DNS or domain provider, or a free certificate from another CA), import one from Key Vault, or buy an App Service Certificate. Then bind it to the hostname with SNI SSL. This avoids ASMC entirely while the stale request is investigated.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix.