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?
Marcus McConnell
shared this idea
10 comments
-
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.
-
Josh
commented
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.
-
ΕΨΗΕΛΩΝ
commented
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.
-
Frank
commented
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.
