Support Double Wildcard Custom Domains
For multi-tenant applications, we require the ability for Azure to support double wildcard custom domains.
Single wildcard custom domains are currently well supported, i.e.
catches all unmapped, single subdomain urls e.g. level1ex.mydomain.com, level2ex.mydomain.com etc
The issue (which isn't documented: see forum post below) is that secondary level wildcards are not supported at all by Azure:
e.g. www.level2.mydomain.com will result in a 404 error.
Why is this important? in a multi tenant environment, with lots of customers on different subdomains, it is best from an end-user perspective to support a www. subdomain prefix, as that's what 99% of non-technerati do when navigating to a website!
i.e. typing in www.level2.mydomain.com should be resolvable by Azure, just as single-level domains are, and not result in a 404
this feature has been postponed as it wouldn’t be complete and might be revisited later if standards/supported features by CAs and browsers change (double wildcard certificates are not supported standard, resulting in no way to secure double wildcard domain)
David Worner commented
You can add a wildcard in the Host or Domain section of the option. Similar to a subdomain, Azure Front Door checks to see if your wildcard domain has CNAME record mapping. This DNS mapping can be a direct mapping assigned to CNAME records, or you can use temporary cards.
For further detail visit the Microsoft Wildcard domains Page.
Alejandro Reinoza commented
I would like to set up my SSL certificated application with multilevel subdomains.
Thanks for sharing this post...Having issue with your kindle device? Don’t worry kindle help guide professional team is here to help you. Call our toll free Kindle helpline number any time USA: (+1) 8884800288 UK: (+44) 800 0418324 or visit our website kindle help guides.
Any update on this request?
Stefan B. Christensen commented
This is not an "Azure" feature and nothing that Azure should support by itself. This is the way SSL is defined in the RFC and the only way that can be changed is by changing the RFC.
Se this post for details:
The best way to support it would be to implement it at the right level so fx:
So use a dash, don't use subdomains.
In my opinion its never a good option to do a work around for bad user behavior. Instead of bending a system to support the wrong doing of users, we should all try and educate them into not typing "www." in front of stuff when not instructed to. Or send them a direct link instead.
Should we also add ".*" or ".com" to the certificate because users type ".com" in the end?
Let's say I have a domain with an app on it:
Should the certificates and Azure support "www.coolapp.mysite.dk.com" just because users are doing it wrong?
Dirk Boer commented
This is a really big blocker for SAAS applications with no simple workaround. According to this stackexchange https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain it is actually working on modern browsers.
Any update on an ETA? Could this be months or years?
For us the intention would be to support www.*.<customdomain>. As a workaround we have been redirecting requests to www. to the naked domain so the certificate is valid.
Alan Wallace commented
At our organization, we need to support dynamically generated subdomains multiple levels deep for OCLC EZProxy to give access to library database services. I was very excited to get this software moved to a Docker container hosted in an App Service, only to find this subdomain restriction preventing us from moving forward.
Is the core intention here to support the www.*.<custom domain>? That is different from asking for *.*.<custom domain>.
Shane Garner commented
+3 more....HUGE feature that is needed. If you could provide regular updates or something it would help to set expectations. An estimated timeline would be outstanding!
Jeff Nall commented
+3. We could really use this feature right now. Please consider moving it up the backlog.
This is still under review and we will update when we have news.
Please implement. This is causing me significant issues with clients - many people tack on www when entering an address, causing a very unhelpful Azure 404 error
Matt Zentz commented
What would be even better is to allow a top level wildcard for all domains. Default IIS installations on all Windows Servers start out with this as the default. I think non-shared plans should also allow this since they are on standalone VM's. I started a topic for this here: https://feedback.azure.com/forums/169385-web-apps-formerly-websites/suggestions/15058641-top-level-domain-wildcard-for-websites
Hi. Is there any update on this?
Please add this feature. We will have to move otherwise.
Nicholas Fulcher commented
Is there any update on this? I ran into the same problem this week.
Has this been put on the roadmap? Any ETA?
Tommy Baggett commented
This is such a common pattern for SaaS offerings that I'm very surprised Azure doesn't already support it. Any update on when this capability will be added? Thanks, Tommy