Failed to create App Service Managed Certificate for .fieldworker.ai due to error: Properties.CanonicalName is invalid. Canonical name .fieldworker.ai includes at least one special character. Only letters and numbers are allowed.

Question

Failed to create App Service Managed Certificate for .fieldworker.ai due to error: Properties.CanonicalName is invalid. Canonical name .fieldworker.ai includes at least one special character. Only letters and numbers are allowed.

Prabhat Vaish 20

I am getting the error when trying to create a certificate for a wildcard custom sub-domain added to an app service. The validation in the earlier step does not show any issues, but the create step fails it.

1 answer

Your answer

Answer 1

TP 124.9K Volunteer Moderator

Hi,

App Service Managed certificates do not support wildcards. If you need wildcard certificate you can obtain it separately and then import it and its private key into app service.

Please click Accept Answer if above was helpful.

Thanks.

-TP

Prabhat Vaish 20 Reputation points

2025-05-11T12:55:10.6933333+00:00

Thanks .. a follow-up question.

The app service already has a few non-wildcard custom domains. I am assuming that this kind of setup will work i.e. wild card will be matched only after all other domains are matched. Is that correct?
Prabhavathi Manchala 2,315 Reputation points Microsoft External Staff Moderator

2025-05-12T02:21:35.99+00:00
Hi Prabhat Vaish,

You're correct! When you configure both non-wildcard and wildcard custom domains in Azure App Service, Azure first checks for exact matches with non-wildcard domains (*.fieldworker.ai). After those matches, it will consider the wildcard domain (*.fieldworker.ai) for any unmatched subdomains.

App Service Managed Certificates don't support wildcard certificates, so you need to import one manually, and you can bind both non-wildcard and wildcard certificates, with Azure using the appropriate one for each domain.

To use a wildcard certificate, first bind all non-wildcard domains to your App Service, then obtain and import a wildcard certificate for *.fieldworker.ai, and bind it to that domain. This ensures the wildcard domain is used only after all non-wildcard domains are matched.

https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate?tabs=apex%2Crbac%2Cazure-cli#create-a-free-managed-certificate

https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-bindings#add-the-binding
Prabhat Vaish 20 Reputation points

2025-05-12T04:20:58.04+00:00

Great .. one last point.

Is the last bullet point mandatory i.e. the order needs to be maintained to ensure that the first bullet point is true?

Thanks.
Prabhavathi Manchala 2,315 Reputation points Microsoft External Staff Moderator

2025-05-12T05:11:05.13+00:00

Hi Prabhat Vaish,

No, the order isn't strictly required, but it's highly recommended to bind your non-wildcard domains first before adding the wildcard. This is because Azure checks for exact domain matches first (like portal.fieldworker.ai) before using wildcard matches (*.fieldworker.ai).

Binding the specific domains first helps make sure traffic goes exactly where you want, and the wildcard only kicks in for subdomains that aren’t already covered. It’s not enforced, but it helps avoid confusion and keeps everything working smoothly.
TP 124.9K Reputation points Volunteer Moderator

2025-05-12T15:08:00.4733333+00:00

@Prabhat Vaish To double-check, I tested with 6 different FQDNs on both Linux and Windows app services. I tested with random binding orders and the wildcard certificate was only selected if there wasn't a matching single-name certificate. This is regardless of binding order.

I did not test with SAN certificates.

Based on the above it appears that the frontend layer attempts to use certificate containing the precise SNI first before using wildcard certificate. The one caution I will add is I don't remember ever seeing this behavior documented, although in the rare cases I have had both wildcard and single name I believe it did behave this way.

In general my recommendation is to "keep it simple" where possible and only have one matching binding for each FQDN per web app. This helps avoid potential unexpected behavior as well as lower complexity and administrative overhead.

If you have specific business case that requires certain certificates for specific FQDN then I understand.
Siva Nair 2,420 Reputation points Microsoft External Staff Moderator

2025-05-12T19:55:27.7033333+00:00

Hi Prabhat Vaish,

Just checking back to see , if the last response by TP is helpful, and it helped you to have a resolution. do let us know, we can publish as verified solution, which eventually will help other members who face similar issue, it would be really helpful.

Thanks!
Prabhavathi Manchala 2,315 Reputation points Microsoft External Staff Moderator

2025-05-13T05:34:55.7066667+00:00

Hi Prabhat Vaish,

Just checking back to see if you got chance to check the previous response of TP. And if you resolved and having resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
TP 124.9K Reputation points Volunteer Moderator

2025-05-14T21:30:40.97+00:00

@Prabhat Vaish Any update? Please click Accept Answer to close up this thread or add a comment below if you still need assistance.

Thank you.

Share via

Failed to create App Service Managed Certificate for *.fieldworker.ai due to error: Properties.CanonicalName is invalid. Canonical name *.fieldworker.ai includes at least one special character. Only letters and numbers are allowed.

1 answer