Re: Force usage of a certificate for client authentication
Sorry I hadn't seen the other replies yet, I answered to Robert via mail and had not yet seen the code references Wan-Teh posted. Thanks for all your help! Hmm it's really weird - the code references seem to indicate that the missing (extended) key usage extension is not the reason for the certificate being filtered out. But I again checked the trust settings for the CA certificates. They're fine... Regards, Martin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
On Thu, Jan 27, 2011 at 6:06 AM, Martin Boßlet martin.boss...@googlemail.com wrote: But I again checked the trust settings for the CA certificates. They're fine... Did you check your client certificate in Firefox 4 to make sure it's imported correctly? In Firefox 4, open Options (or Preferences) Advanced Encryption View Certificates Your Certificates. Is your client certificate listed? Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
Did you check your client certificate in Firefox 4 to make sure it's imported correctly? In Firefox 4, open Options (or Preferences) Advanced Encryption View Certificates Your Certificates. Is your client certificate listed? Yes, it's there. But it was also in Firefox 3.6.13, also under Your Certificates. -Martin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
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-crypto@lists.mozilla.org mozilla.dev.tech.crypto newsgroup Now, with my moderator hat off, I write: Hmm it's really weird - the code references seem to indicate that the missing (extended) key usage extension is not the reason for the certificate being filtered out. Correct. 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. 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. -- /Nelson Bolyard -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
On Wed, Jan 26, 2011 at 4:38 AM, Martin Boßlet martin.boss...@googlemail.com wrote: 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. If the client certificate doesn't have any of those extensions, NSS should allow all uses: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.crev=1.109mark=453,458-459,469-470#448 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certdb/certdb.crev=1.109mark=692,703-705#691 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? I think so. I am not familiar with that part of the NSS code, so I can't summarize the certificate selection algorithm. But I think a client certificate without any of those extensions should be allowed for all uses. I wonder if you didn't import the PKCS #12 file correctly, or it's missing a required intermediate CA certificate. Please open Tools Options Advanced Encryption View Certificates Your Certificates. Does it show the client certificate you imported? Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Force usage of a certificate for client authentication
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
Re: Force usage of a certificate for client authentication
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
