Thanks for all the info guys. I'm half happy and half sad to report
that my troubles were a configuration issue on the LDAP server. I was
running ssltap as suggested and noticed my app was working. I figured
there was no way ssltap had cured my problems so I was scratching my
head. Not 60 seconds later I got an e-mail from our sys admin saying he
had tweaked a security setting on the server. I turned off ssltap and
sure enough my app still worked.
But all this does bring up a valid point, which is probably more
appropriate for dev.tech.ldap. But why doesn't the JSSSocketFactory
class allow me to specify client authentication and the cert name to
use? Even though my problem was on the server, I still had to modify
the JSSSocketFactory class to allow my code to pass in the cert nickname
(since it's different for each user). It seems like the class won't
work unless it knows the cert name (but again, I am new to this).
Anyway, thanks to everyone for the help, and I apologize that all this
time was spent over a config issue.
Mike
Steve Parkinson wrote:
Nelson B wrote:
Steve Parkinson wrote:
To verify this, you might want to turn on SSL Tracing. Use a debug build
of NSS, and then run with the env variable SSLTRACE set to, say 100. It
will spit out tons of debug info - search for the string
'Request-Certificate', which indicates the server is asking for the
client's certificate.
I think a much simpler initial step is to use ssltap to capture the
connections and their SSL handshakes. Most of the time that will show
an obvious problem with the request coming from the server. In the case
where it seems the server did well, and the mystery is why the client
didn't respond to it, then it may be time to try SSLTRACE. But that's
not the first tool I'd use.
My reasoning was that if the server WAS sending the Request-Certificate
message, that might be encrypted, and thus not visible to ssltap, so
Mike might wrongly conclude that the server was misconfigured.
Its certainly good to be familiar with all these methods for debugging.
Steve
_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
