Michaeal,
So your client is stepping up from http://host/ to https://host:444/ after first 
getting
a session in the http mode?   I tried this on my own setup and at least from
http://host/app to https://host:443/app I kept the session going.  Note that I
deleted the c**p in httpd.conf about broken IE and kept keep-alive.

This worked with both IE 5 and NS 6.2.

Regarding multiple SSL servers, the easiest is to give them unique IP addresses.
IIS (which I also use) requires this I believe.  But this may not be an option for you?

/anders

----- Original Message ----- 
From: "Michael Welsh" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 13, 2002 17:44
Subject: Re: Multiple SSL ports


Anders,

Thanks for getting back to this. Here is a better way of looking at what is going on:

I already have an app that uses https on port 443 and uses it's own SSL certificate. 
Since it is on
the standard 443 port I don't need to tack it on to the server name when I need to 
activate SSL.

Now I have another app that will use a different certificate. Since Apache virtual 
hosting doesn't
allow fo named virtual hosting on SSL (I verified that with Verisign), the only way to 
do things is
by using a different port number. I therefore tack change my server name from 
http://host/ to
https://host:444/ when I active SSL. This works quite well for everything that 
concerns https. The
problem that I am having is that Tomcat assigns a new session ID to the client when 
this transfer is
made, and any session objects that client had are lost.

Can you tell me why this is happening or how I can get around it? In exchange I will 
grant you
eternal consciousness.

Michael




Anders Rundgren wrote:

> Michael,
> I'm up to my eyeballs in SSL-problems using TC but maybe I can help.
> You have:
> https://host:443/
> https://host:444/
> This indicates that you have two _different_ applications and they do not share 
>session content.
> To let them share session requires authentication mechanisms that is not likely to 
>be a part of
> the current TC.
>
> If they are one app I see no point in having two ports.
>
> But maybe you mean that you use http and https to the same app.
> That should work.  At least if you step-up from http to https, it works for me at 
>least.
> The other-way-round should be disabled by browsers for security reasons
> although IE don't care...
>
> Anders
>
> ----- Original Message -----
> From: "Michael Welsh" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, March 13, 2002 14:37
> Subject: Multiple SSL ports
>
> Greetings,
>
> I have a server running Apache 1.3.22 and  Tomcat 3.3 on Solaris 8. Up
> until now my Tomcat configuration included just one webapp and it used
> the standard port 443 for SSL (through Apache). That all works really
> well.
>
> Now I am trying to integrate a second webapp, and therefore a second
> context that will use a different SSL certificate. This is no problem
> for all http requests since they all use port 80, but https ports are a
> different story. Since 443 is already used for the first context, I am
> forced to use a different port for the second, and to include it in my
> URL (i.e. https://www.xxx.com:444/). That too works fine now that I got
> it set up correctly in my Apache configuration file.
>
> So here's the problem: The client will surf through the site and collect
> his set of session objects (cart, etc.), but when it comes to to
> activate the SSL, Tomcat seems to look at that URL as if it were a new
> user, therefore assigning it a new session. The client looses his cart.
>
> Any ideas of how I can make Tomcat not pay attention to the port for the
> server information?
>
> any help would be a blessing
>
> Michael Welsh
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Reply via email to