Azure Static Web Apps custom domain returns 404 and incorrect SSL certificate

Hi Allan, Thank you for your detailed response. I followed your troubleshooting steps and here are the results. 1. Custom hostname status: az staticwebapp hostname show --name manish-portfolio-ui --resource-group DevPortfolio-RG --hostname www.manishtechnologysolution.com Result: { "domain": "www.manishtechnologysolution.com", "error": null, "status": "Ready" } 2. Hostname list also shows: www.manishtechnologysolution.com Status: Ready errorMessage: null 3. DNS verification: www.manishtechnologysolution.com -> proud-stone-0c4d65500.azurestaticapps.net -> Azure Traffic Manager -> Azure Static Web Apps edge The DNS resolution is working correctly. 4. The default Static Web Apps URL works correctly: https://proud-stone-0c4d65500.7.azurestaticapps.net returns HTTP 200. 5. However, the custom domain still returns: https://www.manishtechnologysolution.com HTTP/1.1 404 Site Not Found 6. I also checked the TLS certificate using OpenSSL. The certificate currently presented for the custom domain is: CN=*.msha-slice-0-hk1-1-ase.p.azurewebsites.net The Subject Alternative Name does NOT contain: www.manishtechnologysolution.com This seems to confirm that the request is reaching the Azure edge, but the custom-domain hostname is not being correctly mapped to the Static Web App at the edge/certificate layer. The custom domain is already showing "Ready" in Azure, DNS is resolving correctly, and the default Static Web App is healthy. I have not removed and re-added the custom domain because you advised against doing that while the resource reports Ready. Could you please advise whether this needs to be escalated to the Azure Static Web Apps engineering team to investigate the custom-domain edge mapping and managed TLS certificate provisioning? I can provide the --debug output and additional DNS/TLS diagnostics if required. Thank you.

Hello @Manish Agrawal

Since the default azurestaticapps.net URL works and the custom domain already shows Validated/Ready, I don't think this is an application deployment issue.

The combination of these two symptoms is particularly important:

www.manishtechnologysolution.com returns 404 Site Not Found

*TLS presents .msha-slice-0-hk1-1-ase.p.azurewebsites.net instead of a certificate containing your custom domain

That suggests the request is reaching Azure Static Web Apps infrastructure, but the custom-domain hostname binding/certificate provisioning isn't being applied correctly at the serving edge.

Azure Static Web Apps normally creates and manages the SSL/TLS certificate automatically after you successfully configure the custom domain.

First, confirm what Azure currently has registered for the hostname:

az staticwebapp hostname show `
  --name manish-portfolio-ui `
  --resource-group DevPortfolio-RG `
  --hostname www.manishtechnologysolution.com

Also run:

az staticwebapp hostname list `
  --name manish-portfolio-ui `
  --resource-group DevPortfolio-RG

The CLI supports both commands for inspecting the custom-domain configuration.

I would also verify public DNS independently: nslookup www.manishtechnologysolution.com

It should ultimately resolve through the CNAME to: proud-stone-0c4d65500.7.azurestaticapps.net

If that is correct, then DNS is probably not the problem.

One troubleshooting option is to remove and re-add the custom-domain binding. However, I wouldn't do that immediately if this is a production site. There are currently reports of new Static Web Apps custom-domain provisioning operations failing, so removing a binding that Azure currently considers Ready could potentially leave you unable to recreate it.

Instead, I'd first capture:

az staticwebapp hostname show ... --debug

and the output from hostname list.

If DNS is correct and Azure still reports the hostname as Ready, but the edge still serves 404 Site Not Found along with an unrelated *.azurewebsites.net certificate, escalate this to Microsoft Azure Support.

I'd specifically ask them to investigate the Static Web Apps custom-domain edge mapping and managed certificate provisioning for this hostname.

The fact that the certificate presented doesn't contain www.manishtechnologysolution.com is especially useful evidence. This isn't what I'd expect from ordinary browser caching or an application routing problem.

Microsoft documents that custom domains are mapped to the Static Web App and that SSL/TLS certificates are automatically created for custom domains.

Sharing these references with you:

Microsoft - Custom domains with Azure Static Web Apps

Microsoft - Azure CLI: az staticwebapp hostname

I would avoid deleting/recreating the Static Web App itself. The default hostname working correctly indicates that the application resource and deployment are healthy; the evidence points specifically toward the custom-domain binding/certificate layer.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.