Multiple SSL and Domains to One App
We have a multi-tenant application where each client has their own domain name mapped to the service. They also require an SSL certificate so that both http:// and https:// are working. As far as I know, SSL requires a unique IP for each certificate. Multi-domain certificates won't work because they support a limited number of domains and aren't flexible enough to handle adding/removing sites.
Our existing infrastructure uses ARR on Windows 2008 to handle SSL and then load balance out to the web servers without SSL. Perhaps multiple IP support on Azure VM roles would work?
To allow hosting multiple (SSL) sites or domains for the same site on a single Windows Azure role.
SSL only requires multiple IPs when the client is on Windows XP, using an older version of Internet Explorer. Most modern browsers support SNI (Server Name Indication) and thus don’t require multiple IPs.
Support for multiple IPs is under review in the team.
Tim B commented
I find the answer from Corey Sanders to be inadequate. I am trying to migrate a system to azure and because there is no well documented way to have more than a single IP SSL working with a VM my customers are going with another provider, probably AWS.
Its a very common setup to have a web server VM with multiple public IP's for SSL purposes because not everything is consumed via a browser and therfore can be fixed with SNI such as the case with my client and their WCF consumers.
While SNI is great, by ignoring the needs of your potential customers for basic functionality available in other providers and bare metal your only keeping people off your platform.
Ekin Caglar commented
Even with SNI, it is not possible to host multiple sites with wildcard certificates, such that the following scenario would be served via https:
To support this either IIS should support wildcards in hostname (e.g. *.siteA.com) or we would need multiple public IPs associated with the Web Role.
Loren Paulsen commented
@Zoltán, unfortunately not: "Internet-facing VIP is only supported on the 'default' NIC, and there is only one VIP mapped to the IP of the default NIC" (http://azure.microsoft.com/blog/2014/10/30/multiple-vm-nics-and-network-virtual-appliances-in-azure/)
Zoltán Lehóczky commented
Isn't this now available with multi-NIC support for VMs? http://weblogs.asp.net/scottgu/azure-new-marketplace-network-improvements-new-batch-service-automation-service-more
When is this going to be available? It has been two years and this is a must have for any hosting environment. I will have to make a decision to go to another host if this isn't done soon.
Brian Vallelunga commented
Is there any work being done on this? It was requested two years ago and has a huge amount of votes. We'll have to consider another cloud provider without this feature. Multiple IPs for apps and Web Sites is still a must-have feature for many people due to the SSL restrictions.
There are a lot of people still using Windows XP. So SNI is still really not practical for public websites.
Paul Ulvinius commented
At least SNI should be configurable through the InputEndpoint element in ServiceDefinition.csdef.
Gonzalo Parra commented
I agree, I don't mind paying a fair monthly fee for extra VIPs, really important for several reasons, not only multiple certificates but depending on the purpose of the server this is critical...
Scott Cate commented
Plese let me add X IP's at $Y.yy/US per month to my hosted service. Problem solved. The box and the OS can handle it, but I have a feeling the Azure Fabric somehow falls down here, hence the roaming IP's we have today. I would guess that when we have static IP's we'll have the option for Multiple IP's which will then solve this problem.
Until then we're hacking a reverse DNS proxy for SSL on n Domains against one hosted service.
A must have for multiple SSL sites on same machine
You can run two SSL websites on the same IP with different ports: http://stackoverflow.com/questions/5734150/multiple-websites-on-same-ip-with-different-ports-withiis Granted this is won't do for two or more production sites, but for Ben Mills' staging/production on the same box requirement, it fits the bill. That's what I did to solve the same problem as Ben.
Ben Mills commented
This is disappointing. I'm trying to run my staging and production IIS sites on the same VM. You could argue that they should be on different VMs, but that gets expensive.
Vincent Miceli commented
This is also critical for us and the many clients we host via our site. Its also something we are willing to pay for. SNI doesn't work on Windows XP, it would be great if it did. It would also be great if all the corporations were forced to upgrade their aging desktop computer fleet. We are an insurance company and a good majority of users log into our sites from work and we a still seeing a large population of XP, so mutliple IP support is still required at the moment.
I disagree with Brian. I've found that major mobile browsers, Firefox for Android, Chrome and Safari implement SNI. Until we get IPv6 on client networks SNI is a good option. I upvote this idea because there is a fair balance between security and compatibility when using SNI. My hosting platform auto redirects you to SSL if your browser supports SNI, but still allows you to use HTTP if it doesn't: it's up to the client to choose whether to update the browser or not.
Marcus McConnell commented
Wildcard certs won't work because A) they have a limit to about 25-30 domains and B) we need to generate domains on the fly and the time required to issue a new SSL cert would be too long.
SNI is probably the best technical solution but XP and Mobile support is lacking. Another alternative is to provide a custom DNS system like Amazon's Route 53 that extended normal DNS to allow root domains to map to a CNAME but automatically updating a dynamic IP. This has a downside of requiring the customer's DNS to run on Amazon or a special Azure DNS but it might work. Another option (but costly) would be to setup separate virtual machine instances that did nothing but reverse proxy into the normal subdomain style endpoints. This also has a setup time cost in addition to processing cost.
To me a best case solution would be an ARR style system where we could pay for an additional IP address and then map that IP to an Azure application.
Alexey Shcherbak commented
You can use wildcard certificate if you need secure only one more subdomain level.
Wildcard certs can't have Extended Validation mark, but all other features work fine.
You can obtain and secure your custom domain + all subdomains, ex. basedomain.com as main name + *.basedomain.com into the SAN certificate field. It will also work fine for azure deployment, but I don't know how you can drill down azure firewall which won't allow random hostheader in header even if your webrole will be able to handle it. Also take into account that there is limitation (very few, like 25 domains AFAIR) for the number of allowed bindings in azure role config (true for SDK 1.6)
Brian Vallelunga commented
SNI is going to be useless for the next few years unfortunately. There's just too little support, especially among mobile browsers.
Without this feature, I likely can't deploy our solution to Azure, as I have the exact same needs. In fact, we don't need HTTP at all, just HTTPS.
Server 2012 supports SNI, but this is not a good excuse not to implement this feature. Having multiple Ip addresses is critical for mail servers, reverse proxies, etc. Azure can charge for the additional IP addresses, but we need them.
Also enable for Azure Web Sites Reserved Instances to allo for many SSL Certs