views:

212

answers:

4

I have written an ASP.NET MVC application that allows the user to specify their own custom domain. I have IIS configured to send all requests to the default website so I do not need to use host headers. Everything works perfectly. The only problem is SSL.

I know this question has been asked multiple times in many forums but the answers generally conflict or speak in absolutes like (this cannot be done). That's not really an option for me. What I'm looking for here are some options; I'm open to unconventional :).

I have seen some constructive responses that suggest using ISA server as an SSL proxy. Does anyone know more about this? Or has anyone configured this and had success?

Basically I want to provide the my users a way to request a CSR from the application, go purchase and download an SSL certficate, come back to my application and upload the certificate issued by an authorized certification company.

I'd like to do this without having to provide separate IP addresses to clients that want to use a custom domain and ssl on their site. This is simply because my application is hosted on the Amazon cloud and they're not keen on giving me a big block of IP addresses.

My application can be hosted on IIS6 or IIS7 if that makes a difference.

SOLUTION: Thanks for all your help on this guys. I certainly didn't understand this problem as well as I do now. I think my solution for now will be to generate a wildcard certificate and force my clients to use clientname.someshareddomain.com if they want a secured connection. For clients that simply aren't OK with that, I will probably provision another elastic IP address via api call to amazon web services, create a new website in IIS and point it at my application's root folder, and then programatically generate a CSR from that new site. I'm just going to have to work out some kind of deal with Amazon to give me a decent block of IP addresses.

+2  A: 

Every SSL cert requires a unique IP address. That's just the way the technology works:

http://info.ssl.com/Article.aspx?id=10076

Another option would be to purchase a wildcard SSL certificate for *.securedomain.com, then give users a secure sub-domain like website1.securedomain.com, website2.securedomain.com, etc.

Edit: It's one certificate per IP Address / Port. So you could run multiple certificates on securedomain.com:443, securedomain.com:444, etc.

Edit #2: Well, well, looks like there's at least one CA that sells multi-domain SSL certificates: http://www.geocerts.com/ssl/tbidmd

pygorex1
Is this an IIS thing or a technology thing. I know of an other application that is currently doing what I need to do. Zendesk.com allows you to enter your own domain like support.mydomain.com and then generate a CSR. Pinged support.zendesk.com (their product support portal) and then pinged my custom domain at support.mydomain.com... they both have the same IP. How do you think they are doing this?
Jeremy Seekamp
No, a single certificate may contain multiple IP addresses / domain names. Whether you can find a CA willing to issue such a certificate is another question. Port numbers are not a part of the certificate.
GregS
+1  A: 

Well your first hurdle is the multiple domains and SSL certificates. I have yet to see it done as IIS does not know how to respond to different host requests with different ssl certs.

If you wanted to do something like Client.SecureYourCompanyName.com .... that could work...

or ... and dont kick me for this you can set up multiple virtual servers each with their own SSL and have some sort of "load balancing" like setup for the host server which routes according to hostnames... a nightmare to control but it would work...

Hurricanepkt
Yes I am aware of using a wildcard with client.productname.com. I'm actually doing that now; however there are clients that will not be happy with this solution. I get what you're saying about the virtual server thing, but that's more of a pain to manage than multiple websites for each client.productname.com site.
Jeremy Seekamp
+2  A: 

This is a tricky problem. The basic problem is that the SSL connection is established before the HTTP connection can send the Host header.

There's a TLS extension called Server Name Indiccation which is slowly being adopted, but is still not supported by IIS.

Yuliy
So this is an IIS thing. If I were running Linux with openSSl this wouldn't even be an issue?
Jeremy Seekamp
I wouldn't go so far as to say it wouldn't be an issue. Not all browsers support SNI. See http://en.wikipedia.org/wiki/Server_Name_Indication for details.
Yuliy
A: 

I'm not sure I understand your question. If you are asking if you can host thisdomain.com and thatdomain.net from the same ip address and even the same box, the answer is yes, absolutely. The only requirement is that the host name in the certificate matches the URI the client is dereferencing. So, if the user types https://www.thisdomain.net into his browser, then he needs to see a certificate from the server that says www.thisdomain.net in it. That's all there is to it.

GregS