SSL Forms Login for multiple sites

Discussion in 'ASP .Net Security' started by JerryMorton233@mail.com, Feb 19, 2005.

  1. Guest

    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
    , Feb 19, 2005
    #1
    1. Advertising

  2. Geir Aamodt Guest

    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:...
    > 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
    >
    Geir Aamodt, Feb 21, 2005
    #2
    1. Advertising

  3. Guest

    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? :)
    , Feb 22, 2005
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gareth
    Replies:
    0
    Views:
    372
    Gareth
    May 13, 2004
  2. Replies:
    0
    Views:
    289
  3. Alexio

    Authentication forms and SSL on the login page

    Alexio, Nov 24, 2003, in forum: ASP .Net Security
    Replies:
    0
    Views:
    124
    Alexio
    Nov 24, 2003
  4. Gareth
    Replies:
    0
    Views:
    118
    Gareth
    May 13, 2004
  5. Keltex
    Replies:
    1
    Views:
    392
    Dominick Baier [DevelopMentor]
    Jan 24, 2006
Loading...

Share This Page