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
