How can we improve Azure Storage?

make it possible to use SSL on blob storage using custom domains

Currently you can use SSL but you have to user the standard URL. You can create a CNAME to your storage account but most browsers complain that the traffic was rerouted and is possibly an attack. There should be a way to install a domain certificate to your containers.

3,676 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Tobin Rysenga shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    You can now use the Azure CDN to access blobs with custom domains over HTTPS. See the following article for instructions on how to do so: Having talked to a number of customers, we concluded that this solution addresses many scenarios where the need for HTTPS access to blobs with custom domains exists.

    Native Azure Storage support for using SSL to access blobs at custom domains is still on our backlog. We would love to hear about your scenarios where using the Azure CDN is not an acceptable solution, either by posting on this thread or sending us an email at


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Paul commented  ·   ·  Flag as inappropriate

        We absolutely need this feature because of the many valid reasons already provided in the comments. As mentioned by others, the CDN solution is overkill.

      • Nisse commented  ·   ·  Flag as inappropriate

        CDN is designed for huge amount of requests from all over the world.

        It is a poor solution for an enterprise solution for a small number of users.

        Placing images and other data in a completely different domain raises a lot of usability issues when it comes to web browser security.
        Downloading stuff from the same parent domain is normally considered more secure and does not raise issues with many off the ad blockers out there.

      • Peter Andersson commented  ·   ·  Flag as inappropriate

        For our use case being forced to use a CDN just add another layer without any benefit. The files we are publishing to blob storage might be downloaded once or twice so using a CDN is a huge overkill and we mostly likely will not get any benefits from the caching the CDN provides.

      • RentHQ commented  ·   ·  Flag as inappropriate

        This is a must-have feature! Most things these days should be https. By not providing it, seems like a security issue you are ignoring. And I dont accept CDN as an acceptable work around.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Nearly six years? That's depressing. Condolences to those who have been waiting a lot longer.

      • Anonymous commented  ·   ·  Flag as inappropriate

        It's honestly ridiculous that this _issue_ has existed for years when it should be treated as a high priority *bug*

      • Anonymous commented  ·   ·  Flag as inappropriate

        We mostly do not want to directly expose the storage URLs to customers as it contains more information than we'd like to disclose.

      • Fred commented  ·   ·  Flag as inappropriate

        Come on MS - you dont need to ask peoples opinion on it. Obviously this feature should have been in from day 1.
        It sounds like someone is stalling for some reasons - either they don't want to do the work (unlikely) or MS prefers to force us to pay for CDN usage when it is absolutely not warranted.
        Either way this is a real shame - truly a real shame...
        And asking your customers to jump through hoops to fill in web form to ask - plead - beg you... - to do something so simple and so essential is a disgrace.
        Anyhow - here I am having to fill this form to try to explain why such feature is mandatory:
        - obviously http access is a must
        - obviously it needs to be https since http alone is almost never going to work for most scenario.
        - obviously custom domain is an absolute must for any cloud service. Otherwise it would simply be another PAS.
        So here you have it - we need https access and we need custom domain. Simple as that. And of course we need this 5 years ago.

        This is so obvious it pains me to read the admin comment on the top of this page.

      • Lighter commented  ·   ·  Flag as inappropriate

        I have to move to AWS because I wait for this one year.
        You don't care customer's mind.

      • Chris commented  ·   ·  Flag as inappropriate

        This is absolutely crazy that this is not completed by now! There are 3263 votes and this has been an issue for 5 years. This could be the difference between a corporation going with Azure versus AWS. This needs to be addressed. A redirect is not appropriate and the CDN is not the answer.

      • Marcus Kern commented  ·   ·  Flag as inappropriate

        Secure File Transfer from blob storage for distributed file sharing. for instance: our work provides assessments for each "client" these assessments are downloadable, where in they are generated on the fly. our hope is one day to be able to obtain a long term cache (historic deployment and version control) for activity monitoring and update policy violations.

        providing a secure way to distribute these documents would make Azure Storage Blobs a simple solution when compared to other options available but without SSL, this path is not an option.

      • Tamas commented  ·   ·  Flag as inappropriate

        Serving static pages from a blob is a mess. Cannot specify default content and SSL is not possible using custom domains.

        Why I need SSL? Now that's a different story:
        I'm using Azure B2C directory and Azure functions. B2C is only allowing HTTPS callbacks. Which is a bit too strict. There is one usecase where it is not necessary:

        I have a single web page application and the token is returned using html anchors. (#hash). The connection to B2C is under https, so as the redirect directive when the authentication was finished.
        Then the next GET won't include the part of the URL after the #, so it will never leave the browser, only the app could read it (then redirect away from it).

      ← Previous 1 3 4 5 6

      Feedback and Knowledge Base