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: https://docs.microsoft.com/en-us/azure/storage/storage-https-custom-domain-cdn. 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 firstname.lastname@example.org.
If this has been "Completed", why does it still say "Azure Storage does not yet support HTTPS with custom domains. While we do not have a specific timeline we can share for this feature, we are aware of customer interest." at https://docs.microsoft.com/en-us/azure/storage/storage-custom-domain-name?
Could it be that the completion does not refer to the original feedback request (blob storage), but only to CDN instead?
With support for Letsencrypt please (auto-renew, etc.)
We are looking at options to enable this.
It seems like Amazon just did much better (AWS Certificate Manager), adding pervasive support from provisioning and managing of certificates, to automatic incorporation in load-balancer and CloudFront.
In a somewhat striking contrast, Microsoft is satisfied with declaring the need "community solved"... :(
Great, now please connect with your fellow Azure colleagues, and see what can be done to add pervasive Letsencrypt support across the Azure ecosystem (for VM endpoints, CDN, blob storage, etc.
Let's Encrypt support in Azure should become as easy as ticking a single checkbox. Once set, it should request, install and auto-renew as necessary.
More than six months ago everybody was promising this (people from Microsoft on blogs and forums: "it is a very critical scenario and we are working on this functionality"... "you can expect to hear from us on the capability to reserve the IP of an existing deployment"...)
Your most loyal customers are those who already had systems running when these announcements were made. Systems are still being carefully rebooted without external shutdowns to avoid losing virtual IPs, but this is not how a modern system should be managed, is it? This sounds a lot like "Sorry, if you badly wanted this feature you should have done this on Amazon."
Thanks for the idea! We will consider this as we make improvements in the API.Anonymous shared this idea ·
Offering IPv6 support across Networking is a high priority for us and we are actively working to deliver this.
Glad to see your reponse. Hopefully this will be integrated with the "BYON" mentioned elsewhere?
Reactivating this request…apologies that it was closed due to misunderstanding of your intent.
We’ll take this request as: I need a simple way to host IP space that I own as Public IP’s in Azure which I can then use on my Azure-hosted services/VM’s.
We’ve had multiple requests for this feature recently and are actively working through the design now. Unfortunately, we don’t have an estimated release date yet.
We are currently looking at adding native support to VHDX. No committed date, just yet.