Azure API Management returning "404 Web Site not found" with no infrastructure changes

anthony 81

Environment

Azure API Management (managing custom domain + SSL)

Problem

Our API has begun returning errors for all requests despite no changes having been made to our infrastructure.

When navigating to an endpoint via the APIM-managed custom domain in the browser, we first see:


ERR_CERT_COMMON_NAME_INVALID

Proceeding past the certificate warning then shows:


404 Web Site not found.

You may be seeing this error due to one of the reasons listed below:

* Custom domain has not been configured inside Azure.

* Client cache is still pointing the domain to old IP address. Clear the cache by running the command ipconfig/flushdns.

Bypassing APIM and hitting the backend endpoint directly confirms the API itself is online and responding correctly. The issue appears to be isolated to the APIM-managed custom domain layer.

What we have verified

✅ Backend API is online — direct requests return expected responses
✅ Managed certificate has not expired (confirmed in Azure portal)
APIM backend URL is set to [confirm hostname]

Support Ticket

We attempted to raise a support ticket via the Azure portal but were unable to complete the process despite having an active support plan and the appropriate permissions. We are posting here in the hope of getting some guidance in the meantime.

Question

What could cause this and how should we go about resolving it?

Any guidance appreciated. Thanks.

Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-03-02T02:25:13.0033333+00:00

Hi @anthony

Thank you for reaching out to Microsoft Q&A.

Based on the symptoms you described, this issue is not related to the backend API or a recent infrastructure change on your side. The combination of ERR_CERT_COMMON_NAME_INVALID followed by 404 Web Site not found indicates that Azure API Management (APIM) is no longer correctly binding your custom domain and SSL certificate to the APIM gateway. Although the certificate may still appear valid and unexpired in the Azure portal, Azure periodically performs background revalidation of custom domains (DNS resolution, CNAME mapping, and certificate association). If this validation fails—for example, due to DNS proxying, certificate refresh issues, or a transient platform update—Azure can silently detach the custom hostname from the gateway. When this happens, requests never reach APIM and are rejected at the Azure edge, resulting in the observed certificate mismatch and 404 error, even though the backend API remains healthy and accessible directly.

Refer below points to resolve this issue or use these as a workaround:

Verify DNS resolution for the custom domain Ensure that the custom domain CNAME resolves directly to the APIM default hostname (<apim-name>.azure-api.net). If the DNS lookup returns IP addresses from a CDN, proxy, or WAF (such as Cloudflare with proxying enabled), Azure’s domain revalidation may fail and cause the gateway binding to break. Confirm using an external DNS lookup tool and correct the CNAME if required.

Force rebind of the custom domain in APIM Remove the affected custom domain from the APIM → Custom domains → Gateway configuration, save the change, and then re-add the same domain with the associated certificate. This action forces Azure to reapply the hostname and SSL binding to the gateway and resolves most cases where the binding was silently dropped during background validation.

Check certificate configuration and compatibility Verify that the SSL certificate used for the custom domain is in PFX format, includes the full certificate chain and private key, uses RSA encryption, and that the CN or SAN exactly matches the custom domain hostname. Even if the certificate is not expired, an invalid or incompatible certificate can cause APIM to reject or detach the custom domain without a visible portal error.

Avoid DNS proxying for the APIM custom domain If you are using a DNS provider that supports proxying (for example, Cloudflare), ensure that proxying is disabled for the APIM custom domain or that a bypass rule is configured. Azure API Management expects DNS validation to resolve to *.azure-api.net, and proxied responses may intermittently cause domain validation failures after initial setup.
anthony 81 Reputation points

2026-03-02T02:36:14.0233333+00:00

Hi Siddhesh Desai,

Thank you for the detailed response.

DNS CNAME — Verified ✅

I have confirmed that the CNAME records are in place and resolve correctly to the APIM gateway hostname. Please see the screenshot attached below.

Force Rebind — Not possible at this time

Unfortunately we are unable to follow the force rebind step due to the following breaking change announced by Microsoft:

https://learn.microsoft.com/en-us/azure/api-management/breaking-changes/managed-certificates-suspension-august-2025#step-1-allow-access-to-digicert-ip-addresses

Removing and re-adding the custom domain would require us to go through managed certificate issuance, which is currently affected by this change. This makes the suggested workaround unavailable to us without risking further disruption.

Request to Escalate

This issue is causing production disruption for hundreds of organisations relying on our API. Given the severity and the fact that the standard workaround is blocked by a Microsoft platform change, we would like to request that this be escalated and a formal support ticket raised as a matter of urgency.

Please let us know how best to proceed.
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-03-02T02:53:03.77+00:00

Hi @anthony

Can you please fill this form: Create Support Request

I have sent you the same link on Private Chat
anthony 81 Reputation points

2026-03-02T05:39:09.37+00:00
Adding more detail to help with the investigation and to formally request escalation.

We've done some further diagnostics and have identified the root cause. Note that the steps below were performed against our UAT environment (api-uat.t*********.***) to avoid making any changes to production while the issue remains unresolved — however, the same problem is confirmed to be affecting our production environment as well.

Running an openssl check against our UAT custom domain confirms that the wrong certificate is being served at the TLS layer:

openssl s_client -connect api-uat.t******.app:443 -servername api-uat.t********.***

This returns CN=*.azurewebsites.net issued by Microsoft Azure RSA TLS Issuing CA 08 — not our managed certificate (thumbprint [REDACTED], expiry 15/04/2026) which is correctly configured in APIM Custom Domains.

Our conclusion is that the managed certificate auto-renewed on 1 February 2026, but the custom domain binding in APIM was never re-applied after renewal. When we attempted to manually re-save the custom domain configuration to force a re-bind, we received this error:

"The HostnameConfiguration includes a new Managed Certificate Request, which is temporarily not supported during update from August 15th 2025 to March 15th 2026." Correlation ID:[REDACTED]

This directly contradicts the suspension notice which states existing custom domains remain reachable without impact — ours is clearly broken as a direct result of this suspension.

To confirm the diagnosis, DNS is resolving correctly (api-uat.t*******.app → t******-apim-dev.azure-api.net), the managed certificate shows as valid in the APIM portal, and no firewall or NSG changes have been made.

This is a production system serving thousands of organisations globally and requires immediate attention. We are formally requesting escalation to Severity A. We need either a manual re-binding of the certificate on the Azure backend, or direct guidance on an immediate workaround given we cannot wait until March 15 for the suspension to lift.
Rick Drennan 0 Reputation points

2026-03-02T20:39:52.85+00:00

Any Resolution on this? I am experiencing the same issue.
anthony 81 Reputation points

2026-03-02T23:08:24.5933333+00:00

Unfortunately no response/resolution was offered by Microsoft. I suspect something has gone wrong in their managed certificates migration. Since we could not leave our users without service we have disabled managed certificates used letsencrypt to provide an ssl certificate instead. This has fixed the issue for us.
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-03-03T01:12:33.12+00:00

Hi @anthony Can you please fill the form, I have requested above? I can change the Severity to A later
anthony 81 Reputation points

2026-03-03T01:25:13.1566667+00:00

@Siddhesh Desai the form was completed yesteday.
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-03-03T05:29:37.9666667+00:00

Hi @anthonyI have created a ticket with internal backend team, I'll let you know once I receive a response from them.
Patrick Fisher 0 Reputation points

2026-03-03T19:17:10.9333333+00:00

This just hit us last night and into this morning and brought our production down. We were able to roll new certs via Let's Encrypt and after removing the old custom domain and applying the new one we are back in business!
anthony 81 Reputation points

2026-03-04T06:39:11.2066667+00:00

We also had to switch from the Microsoft managed certificate to a self managed one from letsEncrpyt to resolve the issue. For reference it's been nearly 72 hours and no response on our support ticket, so for anyone else who experiences this I would suggest not waiting on a resolution from Microsoft here.
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-04-02T04:35:05.2833333+00:00

Hi @anthony Can you please provide me the details below:

What is your issue in detail?

When did the issue start?

Do you have an example of working and non-working scenario?

Which endpoint(s) are impacted?

Can you provide the OCP trace?
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-04-02T05:59:15.0666667+00:00

Hi @anthony Thank you for confirming that this issue was mitigated by you by moving away from managed certificates. Regarding Azure APIM managed certificate: The Azure APIM managed certificates are suspended as our engineering team is working on some changes and customers are informed the same. The revised dates on when it will be enabled will be updated in the document.

Thank you for your time and support throughout this incident. :)

1 answer

anthony 81 Reputation points

2026-04-02T04:54:02.6466667+00:00

Hi Siddhesh,

Unfortunately, it has been over a month since we reported this issue. Given that it was affecting several thousand of our customers, we could not wait any longer for a resolution.

We have since resolved the issue on our end by moving away from Microsoft managed certificates. Consequently, we no longer require further support.

That said, I suspect this is a widespread issue with managed certificates in APIM. I would recommend contacting other customers who may be experiencing similar symptoms, as this appears to be a broader platform problem.
Please sign in to rate this answer.
Siddhesh Desai 4,895 Reputation points Microsoft External Staff Moderator

2026-04-02T05:59:33.74+00:00

Hi @anthony

Thank you for confirming that this issue was mitigated by you by moving away from managed certificates. Regarding Azure APIM managed certificate: The Azure APIM managed certificates are suspended as our engineering team is working on some changes and customers are informed the same. The revised dates on when it will be enabled will be updated in the document.

Thank you for your time and support throughout this incident. :)
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via