Stuart,
There are several strange things about this trace.
1. There are no SSL/TLS "close notify" alerts being shown prior to the
transmission of the TCP FINs by either side.
Seems unlikely that both sides would fail to send those alerts.
Is the monitor program just not showing them?
Are there possible other SSL/TLS alerts not being shown?
If there are other alerts we're not seeing, they may explain what's really
going on.
2. In SSL record "4 9", the clientHello does not include an SSL/TLS session
ID (called a "resume" in record "4 1"). This is suboptimal, but not wrong.
3. Having requested another handshake ("4 8"), and having received a new
clientHello ("4 9"), the server fails to continue the handshake it requested.
Unless there's a missing alert here, it looks like a server error.
NSS's SSL API allows the application to suppress the use of the SSL session
cache. However, you're using the LDAP SDK API, not the SSL API. I'm not
an LDAP SDK expert, but if there's a way to disable SSL session caching
through the LDAP SDK API, I'm not aware of it. Sorry.
--
Nelson Bolyard
Disclaimer: I speak for myself, not for Netscape
