Hi, thanks for your help!
I considered the custom CA certificate as a reason, too. That's why I verified that the client certificate's root certificate is imported and trusted, as is the root certificate of the server. I also verified with OpenSSL that the remote server sends the entire chain correctly. I can connect without any problems using OpenSSL's s_client command, and I installed Firefox 4beta10 out of curiosity - it works there, too. And finally, I also tried it in Windows with Firefox 3.6.13, where it also failed, but then again worked with IE7. I really think it has something to do with key usage or extended key usage, because my smart card's certificate is recognized (it has key usage digitalSignature and extended key usage Client Authentication) and displayed as an option when I try to connect to that exact server. It's really confusing since with FF4 it seems to work and my client says that it had worked with older FF versions, too. He didn't remember which exact version, but I assume 3.5.x. Regards, Martin 2011/1/26 Robert Relyea <rrel...@redhat.com>: > On 01/26/2011 04:38 AM, Martin Boßlet wrote: >> Hello, >> I'm facing this problem currently with Firefox (3.6.13 Linux): >> >> I want to authenticate to a server using TLS client authentication, so >> I imported a PKCS#12 file for this purpose. >> Unfortunately the certificate is from an internal CA that does neither >> issue keyUsage, extendedKeyUsage >> nor NetscapeCertType extensions. When I tried to connect to the >> server, it failed and my certificate wasn't even considered, >> i.e. I was not asked for selecting a certificate (I had the "ask >> always" box checked). > Most likely you don't have enough of your chain, your server isn't > asking for client auth, and/or you server is not sending the internal > root CA that your cert was issued by. >> From reading previous posts I gathered that when selecting acceptable >> certificates, an acceptable candidate >> must contain the digitalSignature keyUsage and also the >> extendedKeyUsage clientAuthentication. >> I looked through NSS sources and found the following in certdb.c: >> >> case certUsageSSLClient: >> requiredKeyUsage = KU_DIGITAL_SIGNATURE; >> requiredCertType = NS_CERT_TYPE_SSL_CLIENT; >> break; >> >> Is this the code that controls whether a certificate is considered as >> a viable candidate? >> Can you please summarize the exact semantics for the certificate >> selection algorithm? >> >> Then, is there a way to force Firefox into using the certificate I >> imported even if it doesn't meet the >> requirements (Similar to forcing FF to enter sites where host name and >> the CN of the certificate mismatch)? >> The internal CA does not want to issue their certificates any other >> way and I wouldn't like to tell my >> client "Get Windows, install IE, then it should work." :) Maybe >> about:config settings? > I think it's an issue with the server, not the CA. > > bob >> Thanks in advance, >> Martin > > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
