> With my newsgroup/mailing list moderator hat on, I write: > > PLEASE DO NOT reply to this list by multiple addresses. > Please reply to no more than one of the following addresses: > > mozilla-dev-tech-cry...@lists.mozilla.org > dev-tech-cry...@lists.mozilla.org > mozilla.dev.tech.crypto newsgroup
I'm sorry, didn't mean to do that, I simply replied using my mail client, I wasn't aware that I replied to multiple addresses - my apologies. > > > But I again checked the trust settings for the CA certificates. They're > > fine... > > The browser's trust settings have NO ROLE in the choosing of a client auth > certificate when requested by a server. Setting the client's trust > flag on a CA, indicating that the CLIENT trusts it for client certificates > does not, by itself, make the certificates issued by that CA eligible to > be sent by the client to the server in response to server requests for > client auth certs. Does this mean that by default any certificate that's installed under "Your Certificates" would normally be available as a choice for client authentication? Or are some already filtered on the client side? Because imo it wouldn't make sense to filter them client-side - it will ultimately be the server's decision to accept or reject anyway. > What matters most in such requests is the list of CA that the SERVER > trusts to issue client certs. When the server requests that the client > authenticate itself by sending a client certificate, within that request > the server MUST send the list of CA names that it trusts to issue client > certs. The client MUST NOT send back a cert unless that cert is directly > issued by, or chains up to, one of the CAs named in the server's list of > trusted client CAs. It is a violation of the protocol to do otherwise. > > So, you can set trust flags in the client until the cows come home, but > until the SERVER sends out that CA name in its list of trusted client CAs, > an RFC-compliant client will not send any certs from that CA. > Thanks for the hint, I'll trace with OpenSSL whether this is sent correctly by the server. But still, I can't imagine that there's something wrong with that. What troubles me most is that authentication basically succeeds with any other software that I tried except for Firefox 3.6.13. It even works again with 4beta10, so I'm wondering what would be specific to the 3.6 series that wasn't there before and seemingly vanished again in the new version... BTW: Does NSS come with a command line tool that would allow me to connect manually and debug the information sent over the wire? Maybe that could help me better understand why things are going awry. Your help is much appreciated, thank you! Martin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
