«

Hi,
SSL newbie would love some advice

I have a server that hosts several independant domains (using host
headers to differentiate them). Each domain runs an independant copy of
the same ASP.NET application - this app uses forms-based authentication
and a proprietary XML file on each site to authenticate users/passwords
(i.e. each site has it's own set of users).

I would like to implement SSL around the forms login page for each
site, to protect the login process only.

Since SSL is tied to a domain, is there a way I avoid having to buy an
SSL cert for EACH domain?

Thanks for any help!
Jerry

Jerry,

the short answer: No.

As you are saying, the SSL certificate are tied to one domain and this is
done for security reasons. Otherwise, you could have certificates saying
that
"I am site Y", when the site in reality is site X.

What you could try to do (depending on your application/system) is to create
a
common login service which, after successful login, redirects the users to
the correct
domain.

This would of course require a new "logon.yourdomain.com" which would handle
this.


--

Best regards,
Geir Aamodt
geir.aamodt(AT)bekk.no

<> wrote in message
news: ps.com...
> Hi,
> SSL newbie would love some advice
>
> I have a server that hosts several independant domains (using host
> headers to differentiate them). Each domain runs an independant copy of
> the same ASP.NET application - this app uses forms-based authentication
> and a proprietary XML file on each site to authenticate users/passwords
> (i.e. each site has it's own set of users).
>
> I would like to implement SSL around the forms login page for each
> site, to protect the login process only.
>
> Since SSL is tied to a domain, is there a way I avoid having to buy an
> SSL cert for EACH domain?
>
> Thanks for any help!
> Jerry
>

Hi,
I thought this would be the case. I was thinking about the "common
login" process - has anyone done this? I just wonder how the system
will react i.e. when a cookie generated by a forms-authentication page
at "https://logon.yourdomain.com" is then passed back for use under
"http://www.myoriginaldomain.com"? I think there's a way of
manipulating the domain name in the cookie - but what about the "https"
-> "http" bit - does that still form part of the cookie validation?

I was thinking that if I buy a "shared" ("wildcard"?) SSL cert, I can
make something work? i.e. www.adomain.com uses web.config to redirect
unauthenticated users to "https://adomain.yourdomain.com/login.aspx"
which ACTUALLY maps to a page under the "adomain" application (e.g.
"http://www.adomain.com/adomainloginfolder/login.aspx"). I think I
still have the same cookie problems though? Although this would let me
use the correct "user database" for each app more easily.

Maybe some kind person out there has tried this?