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.
*.mydomain.com
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
GS
shared this idea
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)
22 comments
-
Sandro
commented
Well, thanks I spent a full day trying to get a custom hostname binding working with my ARM template... with a message saying the hostnames don't match... it might as well have said that multilevel wildcards are not supported there too, and I wouldn't have lost so much time...
why is this simple thing not working? -
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.https://docs.microsoft.com/en-us/azure/frontdoor/front-door-wildcard-domain
-
Alejandro Reinoza
commented
I would like to set up my SSL certificated application with multilevel subdomains.
-
kindlehelpguides
commented
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.
-
Anonymous
commented
Hello,
Any update on this request?
Thanks,
Jeff
-
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:
https://community.letsencrypt.org/t/allow-multiple-level-wildcard-certificates/67242The best way to support it would be to implement it at the right level so fx:
www-my_funky_sub.domain.com
myapp1.domain.com
myapp1tst.domain.com
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:
coolapp.mysite.dk
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?
-
Henry
commented
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>.
Christina
-
Jonata
commented
+3
-
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.
-
Dave
commented
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
-
dan
commented
Hi. Is there any update on this?
Thanks
Dan -
Anonymous
commented
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.
-
Alex
commented
Has this been put on the roadmap? Any ETA?
Thanks,
Alex.