We welcome user feedback and feature requests!

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

https://social.msdn.microsoft.com/Forums/azure/en-US/4196087d-0ef9-44dc-9192-73e434bdb194/second-level-subdomains-wildcard-domains-on-azure-dont-work-as-expected?forum=windowsazurewebsitespreview

410 votes
Vote
Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
GS shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

19 comments

Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
Submitting...
  • kindlehelpguides commented  ·   ·  Flag as inappropriate

    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.

  • Stefan B. Christensen commented  ·   ·  Flag as inappropriate

    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/67242

    The 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?

  • Henry commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Shane Garner commented  ·   ·  Flag as inappropriate

    +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  ·   ·  Flag as inappropriate

    +3. We could really use this feature right now. Please consider moving it up the backlog.

  • Dave commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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

  • Tommy Baggett commented  ·   ·  Flag as inappropriate

    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

  • Victor Smith commented  ·   ·  Flag as inappropriate

    I use basically unlimited subdomains to personalize email communication links for my customers.
    It increases my click through rates.
    I call is sentence links.
    My Host.com account allows me to go many layers deep with the subdomains.

    Http://Please.Make.This.Not.404.On.Azurewebsites.com

    Thanks,
    Victor Smith

Feedback and Knowledge Base