Further investigation has resulted in an answer. See
http://www.mail-archive.com/[email protected]/msg09443.html
We are using a temporary certificate for testing and the address in the
certificate does not match the address we are using for access to our test
system.
Thanks for the interest.
Mike Bray
-----Original Message-----
From: Bray, Mike
Sent: Tuesday, March 26, 2002 8:09 AM
To: '[EMAIL PROTECTED]'
Subject: RE: SSL Session cache and IDs
Thanks all for the replies. I have done some experimenting with a
SSLCachetimeout of 15s. Even though I can send a request within 15s with
the same session id I get a status of
request=GET status=MISSED id=... (session renewal)
followed by
request=SET status=OK id=.... timeout=15s (session caching)
with a completely new id.
The problem is that our content switch (Cisco) is going sticky on SSL ID and
because the client has a new id it can do what it likes with it. Under load
the switch could send the next request to a different machine. We are not
sharing caches as SSL sessions should be on same machine.
I can understand getting a new ID when the session is dead, i.e.
request=REM status=OK id=.... (session dead)
I have tried this with nokeepalive and without, no difference.
My browsermatch statements are:
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
My SetEnvIf is
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
Regards
Mike Bray
SBS UK
-----Original Message-----
From: Cliff Woolley [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 25, 2002 8:10 PM
To: [EMAIL PROTECTED]
Subject: Re: SSL Session cache and IDs
On Mon, 25 Mar 2002, Mads Toftum wrote:
> The defaults are nokeepalive IIRC - if that affects the session, then
> shouldn't it cut the session short even after the initial request?
nokeepalive doesn't really imply no session caching at all... that's not
exactly what I meant to say. What I was trying to say was that IE doesn't
deal well with sessions in general, which is why kept-alive sessions cause
even more headaches -- IE just does bad things with them. I can't be much
more specific than that because I haven't studied it in depth... but I
just feel like things that would make IE behave better with sessions in
general might make it do the right thing the server asks for a
renegotation in this case.
> Setting SSLLogLevel to something like debug and looking for cache
> hits/misses would probably be a good place to start.
This and testing with/without load balancing both sound like a good
plan...
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
