Hi Rob, On Fri, 2006-01-06 at 09:21 -0500, Rob Crittenden wrote: > Mark McLoughlin wrote: > > Hi, > > A couple of quick questions about things that have been bugging me: > > > > - If I import a server certificate and a CA certificate with pk12util > > and change the trust attributes on the CA cert to "C,," - i.e. that > > it should be a trusted CA for server certificates - and then start > > slapd I get: > > > > [05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate authority is trusted for SSL client authentication. > > > > Which seems strange to me - I would have thought the CA certs in > > nssckbi would be trusted for client auth? > > The C trust flag means that it is a trusted CA to issue server certs. > For client certs you need the T flag as well. Right. > nssckbi doesn't really come into play here. I believe that even if your > CA is signed by another CA that is in libnssckbi but you don't trust > your CA to sign client certs, then any client certificates issued by > your CA won't be trusted. Well, the point is that this CA won't be issuing an client certificates ... only a server certificate. What appears to be happening is that NSS requires at least one CA certificate to be available in order to send a certificate request during the handshake. However, my CA certificate isn't trusted for client auth and NSS isn't aware of any other CAs for client auth, so it barfs. I find this puzzling because looking through the NSS code, it looks like the CA certificates from nssckbi should be used for client auth - e.g. the error suggests that if I make my CA trusted for client auth, it will be the *only* CA used for client auth and that the root CAs will be ignored? Cheers, Mark. -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
