Getting issue/error when updaing the custom domain in APIM

Question

Getting issue/error when updaing the custom domain in APIM

Ritik Mittal 0

We are trying to update the custom domain in APIM and i have Lets Encrypt (certbot) certificate but when i am trying to add the certificate and click on save then after some time it fail to provide me the given hostname as custom domain (i also added cname and txt in my godaddy related to that subdomain) but i am getting this error so can you check

Unable to Update API service at this time. Please check resource group deployment logs for specific errors, correct them and try again.If you are deploying into a virtual network please check the following document https://aka.ms/apimvnet for network requirements. If you still need help from support, please reach out to them.Please provide correlationId 2cb36954-4590-4199-a9af-259e90089d98 and TimeStamp 7/15/2026 5:56:25 AM.

Screenshot 2026-07-15 120652.png

Rukmini 43,815 Reputation points Microsoft External Staff Moderator

2026-07-15T06:50:37.28+00:00
Hello @Ritik Mittal

It sounds like you’re trying to configure/update a custom hostname + TLS certificate on Azure API Management (APIM), but when you click Save the update fails and the custom domain ends up not being applied.

From the error you posted (“Unable to Update API service at this time… check resource group deployment logs”), the most common causes in this scenario are usually DNS/ownership validation issues and/or certificate/key vault access / certificate format issues—depending on how the certificate is being supplied.

Please check:

For APIM custom domains, you need a DNS setup that matches the APIM validation expectations:

Create a CNAME record:

Your custom domain (for example api.contoso.com)

points to APIM hostname (for example <apim-service-name>.azure-api.net)

If you’re enabling a managed/free certificate validation flow, you must also have a TXT record to establish domain ownership.

So please verify:

The CNAME target is correct (points to your APIM service hostname).

The TXT record (if required for your certificate mode) exists and is set to the correct value expected by APIM (ownership verification).

Wait for DNS propagation and confirm resolution externally (if it’s newly added/changed, validation can fail until it propagates).

In APIM custom domain registration failures, there are cases where a TXT record exists but is set to the wrong value—this can cause the update to fail.

If the certificate is from Azure Key Vault:

Your post mentions Let’s Encrypt/certbot, but the underlying APIM behavior depends on whether you:

uploaded a cert directly in the portal, or

referenced a certificate stored in Azure Key Vault

If APIM is using a Key Vault certificate, the update can fail if APIM managed identity doesn’t have permission to read the Key Vault secret/certificate.

Ensure:

APIM Managed identity status is On

The Key Vault has access for the APIM service principal/identity:

Secret permissions: Get (at minimum, as described in the troubleshooting doc)

If Key Vault permissions are missing/incorrect, you can get hostname update failures like the one you’re seeing.

Next step: check the real deployment error details

Because your message says to check resource group deployment logs, the key detail should be in the deployment logs for your APIM update operation. That’s where you’ll typically see the specific failing condition (DNS validation failure, Key Vault Forbidden, cert parsing issue, etc.).
Ritik Mittal 0 Reputation points

2026-07-15T07:02:57.2466667+00:00
Thanks for the response. A few clarifications on my exact setup, since I don't think these solutions apply to my case:

1. I'm not using Key Vault for the certificate. The Certificate type is set to Custom — I'm uploading a .pfx file directly (issued via Let's Encrypt/certbot for this exact hostname). There's no Key Vault reference involved, so Managed Identity / Key Vault access policies shouldn't be relevant here. Please correct me if APIM's Custom cert path also depends on Key Vault permissions internally — I wasn't aware of that.

2. The TXT record was only for certificate issuance, not for APIM itself. I used a DNS-01 challenge with certbot to get the Let's Encrypt certificate — that required a temporary _acme-challenge TXT record, which I added, verified, and certbot successfully issued the certificate against it. That TXT record's job is done; the cert itself is valid (confirmed valid until 2026-10-11). I don't believe APIM's custom domain binding re-checks that TXT record at save-time — only the CNAME + certificate. Is that correct, or does APIM require an additional, separate TXT record I'm missing? If so, what exact name/value format does it expect?

3. What I've already verified, all correct:

CNAME for uatapi-sptteamrocks2030.askthegenie.ai resolves to uat-atg-apim.azure-api.net (confirmed via nslookup)

Certificate is .pfx format, password-protected, valid, issued specifically for this hostname

Certificate uploads successfully in the Portal ("Upload Completed" toast) before the Save fails

No Key Vault involved anywhere in this flow

4. The exact failure sequence, every time:

Add custom domain → Hostname + upload .pfx + password → click Save

Sometimes it shows a specific error like "CNAME not found" (which I fixed)

After fixing that, it now fails with the generic: "Unable to Update API service at this time. Please check resource group deployment logs..."

I checked Resource Group → Deployments — no matching failed deployment appears there

I ran "Diagnose and solve problems" including "Hostname certificate rotation detector" — no issues found

This has now failed 5+ times across 2 days with the identical generic message, correlation IDs: d8789f39-1764-4a42-8d6b-8c7e8ad8727d, 3bf290f8-ec22-4870-8d66-0dfa58d3779f, 5080c867-1013-4dcd-9079-2a79cedc1660, 2cb36954-4590-4199-a9af-259e90089d98

On one occasion it reported "hostnames updated successfully," but the custom domain entry then disappeared from the Custom domains table entirely (only the built-in .azure-api.net hostname remained)

My actual question: given all of the above is correct on my end, is this a known platform-side issue with Consumption tier custom domain updates right now? Should I escalate to a formal Azure support ticket instead of this Q&A, since the generic error message itself points to "resource group deployment logs" that don't show anything actionable?
TP 160.7K Reputation points Volunteer Moderator

2026-07-15T08:17:14.6+00:00

@Ritik Mittal As a quick test I created self-signed cert using powershell, using certlm.msc added cert to Trusted Root Certification Authorities store, exported to pfx, created CNAME record, added custom domain to consumption APIM using pfx, saved, waited 2 minutes, tested with Chrome and it worked fine.

In order to see if you can narrow down problem, can you perform above test on your end? Should only take 5 minutes. And what region is your APIM instance in?
Ritik Mittal 0 Reputation points

2026-07-17T06:06:17.1133333+00:00

@Rukmini

Can you please help in creating the Developer Support Ticket on our behalf. It seems some issue on our APIM and we have tried everything in our side but still no luck. Pls see response from @TP as he also tried to help and check and No luck. Some other community users also facing the same issue.

We have tried with new certificate, loaded certificate on key vault as well but No luck.

At this point, we are hitting the serious blocker which is stopping us to move to UAT and delaying Go live.

Appreciate support from Microsoft Dev Team . Request to open support ticket on our behalf.

Regards
Ritik Mittal
Rukmini 43,815 Reputation points Microsoft External Staff Moderator

2026-07-19T07:05:58.1166667+00:00

Hello @Ritik Mittal We will investigate the issue and update you with the findings. Thank you for your patience as we look into this.
Ritik Mittal 0 Reputation points

2026-07-20T05:44:24.3133333+00:00

Thank You @Rukmini for your response. Appreciate help in resolving this issue as we have been blocked here from almost 3 weeks.

What would be next step ? Will you be able to help by creating MS Developer Support Ticket ?
Ritik Mittal 0 Reputation points

2026-07-22T05:52:05.73+00:00

Hi @Rukmini i, just following up on this issue. Could you please share any update on the investigation? We are still blocked from moving to UAT, and this is impacting our Go-Live timeline. If possible, could you also let us know if a Microsoft Developer Support ticket can be created/escalated? Thanks!
Rukmini 43,815 Reputation points Microsoft External Staff Moderator

2026-07-30T02:50:19.0733333+00:00

Hello @Ritik Mittal Please check private messages!

3 answers

Your answer

TP 160.7K Reputation points Volunteer Moderator

2026-07-15T08:17:14.6+00:00

@Ritik Mittal As a quick test I created self-signed cert using powershell, using certlm.msc added cert to Trusted Root Certification Authorities store, exported to pfx, created CNAME record, added custom domain to consumption APIM using pfx, saved, waited 2 minutes, tested with Chrome and it worked fine.

In order to see if you can narrow down problem, can you perform above test on your end? Should only take 5 minutes. And what region is your APIM instance in?
Ritik Mittal 0 Reputation points

2026-07-17T06:06:17.1133333+00:00

@Rukmini

Can you please help in creating the Developer Support Ticket on our behalf. It seems some issue on our APIM and we have tried everything in our side but still no luck. Pls see response from @TP as he also tried to help and check and No luck. Some other community users also facing the same issue.

We have tried with new certificate, loaded certificate on key vault as well but No luck.

At this point, we are hitting the serious blocker which is stopping us to move to UAT and delaying Go live.

Appreciate support from Microsoft Dev Team . Request to open support ticket on our behalf.

Regards
Ritik Mittal
Rukmini 43,815 Reputation points Microsoft External Staff Moderator

2026-07-19T07:05:58.1166667+00:00

Hello @Ritik Mittal We will investigate the issue and update you with the findings. Thank you for your patience as we look into this.
Ritik Mittal 0 Reputation points

2026-07-20T05:44:24.3133333+00:00

Thank You @Rukmini for your response. Appreciate help in resolving this issue as we have been blocked here from almost 3 weeks.

What would be next step ? Will you be able to help by creating MS Developer Support Ticket ?
Ritik Mittal 0 Reputation points

2026-07-22T05:52:05.73+00:00

Hi @Rukmini i, just following up on this issue. Could you please share any update on the investigation? We are still blocked from moving to UAT, and this is impacting our Go-Live timeline. If possible, could you also let us know if a Microsoft Developer Support ticket can be created/escalated? Thanks!
Rukmini 43,815 Reputation points Microsoft External Staff Moderator

2026-07-30T02:50:19.0733333+00:00

Hello @Ritik Mittal Please check private messages!

Answer 1

Hi,

Based on everything you have described it doesn't appear you are doing anything wrong and there is some sort of a service issue. There is another person experiencing same error as you. Unsure if that person is on consumption in East US 2 as well or different region.

Just now I repeated my test with East US 2 (before I tested on East US) and was successful. It could be an issue with the particular deployment unit your APIM instance is on and not a region-wide problem.

I recommend you create Technical support request if you have Azure support plan. To create Severity A (<1 hour response) request in Azure portal you need at least Standard plan. Below link allows you to upgrade your plan if needed:

https://portal.azure.com/#view/Microsoft_Azure_Support/HelpAndSupportBlade/~/supportPlans

If you choose Developer support (or lower severity case under Standard support) you have to post here on Q & A, instead of creating request in the portal, and then if a Microsoft External Staff person deems it necessary, they will create a technical support request on your behalf. This is why I suggest Standard support plan if possible. If you want you could set plan not to renew so that you are charged for one month.

The above policy is how Microsoft's Priority Community Support works.

https://learn.microsoft.com/en-us/azure/azure-portal/supportability/priority-community-support

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Answer 2

Thanks for the suggestion — I ran the exact test you described (self-signed cert via PowerShell New-SelfSignedCertificate, exported to .pfx, same CNAME already in place, uploaded as Custom type, saved, waited). It did not work the same way on my end — the update sometimes reports "Succeeded" in Activity Log, but the domain still returns a stale/wrong response (Azure's generic "Web Site not found" fallback page, or a cert mismatch), not a working connection like you got in Chrome.

I also tried a third certificate delivery method since posting — Key Vault-backed certificate, with Managed Identity enabled on the APIM instance and granted Key Vault Secrets User (RBAC) + the automatic access-policy grant via the Portal's "Access Key Vault certificates" prompt. This attempt failed outright with the same generic error: "Unable to Update API service at this time."

So across 3 different certificate sources — Let's Encrypt (Custom), self-signed (Custom), and Key Vault — none successfully bind the custom domain on my instance, while your self-signed test worked fine on yours. This makes me think it's something specific to my instance or region rather than a certificate content/format issue.

My APIM region: East US 2

Given self-signed worked for you but fails identically to my other attempts on my end, could this be:

A region-specific issue?
Some corrupted/stuck state specific to this APIM instance that a fresh instance wouldn't have?

New correlation ID from the Key Vault failure: 33b9e8d4-157f-4543-ab6d-51abf3a0c513 (Previous ones already shared: d8789f39-1764-4a42-8d6b-8c7e8ad8727d, 3bf290f8-ec22-4870-8d66-0dfa58d3779f, 5080c867-1013-4dcd-9079-2a79cedc1660, 2cb36954-4590-4199-a9af-259e90089d98)

At this point I suspect this needs a formal Azure Support ticket rather than continued troubleshooting here — would you agree, or is there something else worth trying first?

Answer 3

For APIM custom domain updates, the supported checks in this scenario are:

Verify APIM can read the certificate from Key Vault
- In Azure portal → API Management instance → Security → Managed identities, make sure the managed identity is On.
- Go to Key vaults → the target vault → Access policies.
- Check whether the APIM service principal exists and has Secret permissions: Get.
- If it does not exist, add an access policy for the APIM service with:
  - Key permissions: None
  - Secret permissions: Get
  - Certificate permissions: None
- Save the changes, then retry adding the custom domain.
Recheck DNS ownership records for the custom hostname
- Make sure the custom host name has a CNAME pointing to the APIM default host name.
- Also create or verify the TXT ownership record for the custom host name and confirm the value is correct.
- A documented case with the same behavior was resolved after correcting the TXT value and keeping the CNAME pointed to the APIM default name.
If the certificate is being uploaded as a PFX, verify the file format
- The certificate file must be password-protected and in PKCS#12 (.pfx) format.
- Other formats are rejected.
If the save operation still rolls back after these checks
- A documented APIM case shows that when custom domain updates appear to apply, then revert after the service enters Updating, the issue can be caused by a stuck backend service transition.
- In that case, further portal retries do not resolve it. The next step is to open an Azure technical support request and provide the correlation ID and timestamp from the failed activity log entry so support can investigate and clear the backend state.

Based on the details provided, the most relevant causes are:

APIM missing permission to read the certificate secret from Key Vault.
Incorrect CNAME/TXT ownership records for the hostname.
A backend APIM service transition issue that requires Azure Support.