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

408 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    GS shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    17 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
      Password icon
      Signed in as (Sign out)
      Submitting...
      • 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