On Wed, Feb 07, 2001 at 02:01:27PM +0100, Reich, Stefan wrote:
> This seems to be indeed a session problem. But it's Netscape specific.
> If I look in the log, IE is reusing a session and I can see counters like
> request 1 request 2 request 3 and so on.
> With Netscape these subsequent requests are very rare.
>
> But: Even if IE is sending a new request, I'm not asked for the certificate
> again.
Hmm, no idea about IE, but I can reproduce your problem with Netscape...
I have just ssldump'ed and it seems that Netscape proposes sessions to
be reused, but mod_ssl happily issues new sessions...
I have an idea, let's verify...
* SSLLogLevel trace
- found expected entries looking like this:
[07/Feb/2001 14:53:11 06753] [trace] Inter-Process Session Cache: request=SET
status=BAD id=DAF80CB3346BA4F5AF1B85914695B8FD285C9D0725A36D2029280BEF0F59F8C5
timeout=295s (session caching)
[07/Feb/2001 14:53:30 06719] [trace] Inter-Process Session Cache: request=SET
status=BAD id=9AD1C76F2E88ABCEF3EDBDBAF979B7DA6384BB5B0032D1E8DD32F7DD3B740D16
timeout=295s (session caching)
Sessions are not loaded into the inter-process session cache. If you happen
to connect to the same server process again it will still be in memory
(working fine), otherwise a new negotiation takes place.
* I use sdbm, you too?
* Explanation: I have written the Postfix/TLS patchkit extending the Postfix
Mail Transport Agent to support TLS. Client certificates can be used to
authenticate for relaying.
I am also using SDBM, but I had to change the source to allow larger
blocks, since sessions with client certificates can extend the 1024
byte hard limit. (Further reduce 1024 by the size of the key, in this
case the session ID).
There is nothing you can do as long as you use sdbm. Maybe you can try
shm. I made some experiments on HP-UX with "mm", but it didn't work
well (may well be caused by compiling in mm support for PHP). I didn't
care that much, since i normally don't use client certificates and continued
using SDBM...
Failure may look arbitrary. My certificate was issued by our universities
computer center with the full name of our university and as a sub-CA of
the Toplevel CA, so it is really long:
...
Issuer: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet
Cottbus, OU=Rechenzentrum, [EMAIL PROTECTED]
...
Subject: C=DE, ST=Brandenburg, L=Cottbus, O=Brandenburgische Technische Universitaet
Cottbus, OU=Allgemeine Elektrotechnik und Numerische Feldberechnung, CN=Lutz
[EMAIL PROTECTED]
...
X509v3 Authority Key Identifier:
DirName:/C=DE/O=Deutsches Forschungsnetz/OU=DFN-PCA/CN=DFN Top Level Certification
[EMAIL PROTECTED]
...
X509v3 Subject Alternative Name:
email:[EMAIL PROTECTED]
So with all of the extenions in it it may well exceed the limit. I have
been using self-issued certificates for quite some time without this
problem, but they did not contain that much information.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
