RE: About generating a new rootcert module (nssckbi lib)
I want to be able to load trusted root CA certs and valid (but not trusted) intermediate CA certs. NSS requires an unbroken CA chain up to a root in order to validate a cert, and some SSL apps don't always send a CA chain. -- POC -Original Message- From: Ian McGreer [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 3:15 PM To: [EMAIL PROTECTED] Subject: Re: About generating a new rootcert module (nssckbi lib) Actually, why do you want to create a builtin CA with valid CA trust? The purpose of the builtin module is to supply trusted roots, which is probably why valid CA trust was overlooked - we only use the trusted CA bit. -Ian Ian McGreer wrote: POC wrote: Hello, The addbuiltin cmd creates a certdata.txt, which is then used to build the nssckbi lib. A couple of things about that: 1. The new certdata.txt does not get processed properly by certdata.perl (when doing the gmake generate in mozilla\security\nss\lib\ckfw\builtins); but got it to work (i.e., the certdata.c file gets created and I can gmake the nssckbi lib) by manually adding the CVS_ID at the top of the certdata.txt file; but there's still a problem with the perl script; here's the error message: Name main::a used only once: possible typo at certdata.perl line 212. Can't do inplace edit: is not a regular file at certdata.perl line 48. The addbuiltin command does not create certdata.txt. It is meant to add to certdata.txt. There is some special text, including the cvsid, at the beginning of that file that needs to be processes by the script. As noted in addbuiltin.c, the correct usage is addbuiltin ... certdata.txt. 2. The trust flags specified when running addbuiltin do not stay the same after listing the cert with certutil: E.g., I specified trust flags c,, when running addbuiltin, but certutil shows p,p,p when listing the cert... That sounds like a bug. It appears that addbuiltin does not support valid CA trust (probably because that value was added later). -Ian
Re: How do I set the default Certificate?
Hi, tom glaab wrote: Julien Pierre [EMAIL PROTECTED] wrote In truth, most people do not have more than one valid cert per issuer with a different subject, much less more than one valid cert for more than one issuer. I'm in the minority then, and it is annoying. I've had a corporate cert for years, and it includes an email cert. Now a mandate has come down for everybody to get an identity-only cert from the same corporate CA, even if you already have one. Normally, this is acomplished not by changing the subject of the certificate, but by changing the keyusage. Changing the subject does not make sense if the two certs belong to the same person and are from the same issuer. This tells me your PKI is not implemented correctly. For example, I have two corporate certs, one which is for encryption and another for signing. The subject of both certificates is identical. The signing certificate is used for identification purposes. You can see them both in the signature of this message. I do find it annoying. While it's probably rare to find a person with multiple certs from the same CA I can see it happening more often... a single user may have his normal identity cert but also have a privileged or administrative cert. This probably shows more about the corporation's ignorance of PKI, but that's another story. Well, there you go ... smime.p7s Description: S/MIME Cryptographic Signature
Re: Mozilla, PKCS#11 and MacOSX ???
bk390934 wrote: I'm trying to understand what Mozilla 1.2 and 1.3 for MacOSX are made of. I am a total newbie to MacOSX and I have some basic questions: - is Mozilla a CFM or MachO app? Mozilla 1.2 is a CFM app. I believe Mozilla 1.3 will be a Mach-O app. Please ask in netscape.public.mozilla.macosx to confirm this. - does it use Carbon or Cocoa? Mozilla 1.2 (a CFM app) uses Carbon. I believe the Mach-O version of Mozilla 1.3 will use Carbon, but again please ask in netscape.public.mozilla.macosx to confirm this. Note that there is a Mach-O, Cocoa browser called Chimera that is based on the Gecko embedding environment from the Mozilla project. - does it support PKCS#11 modules that are MachO dylibs? The Mach-O version of Mozilla supports PKCS#11 modules that are Mach-O dylibs. The CFM version of Mozilla only supports PKCS#11 modules that are CFM shlbs. - what are the requirements for PKCS#11 modules specifically for the MacOSX version of Mozilla, where is this documented (didn't find it), what type of library is required? A fully PKCS#11 compliant module should have no problem working with Mozilla. It seems that the authors of some PKCS#11 modules only aim to implement the subset of PKCS#11 that Mozilla uses. Perhaps there are practical problems with a full implementation of PKCS#11. We used to have a PKCS#11 conformance test suite. That test suite is somewhat out of date now because in NSS 3.4+ (used in Mozilla 1.0.1 or later) we started to use more PKCS#11 features. The PKCS#11 features we currently use are not documented. Wan-Teh
Re: About generating a new rootcert module (nssckbi lib)
POC wrote: I want to be able to load trusted root CA certs and valid (but not trusted) intermediate CA certs. NSS requires an unbroken CA chain up to a root in order to validate a cert, and some SSL apps don't always send a CA chain along with their end user cert. I therefore pre-load some of the known intermediate CAs I know will be issuing certs to such apps. -- POC As Wan-Teh pointed out, those servers are misconfigured. However, I will note that at any rate, you don't need to give the intermediate certs valid CA trust. That trust bit is essentially a hack for the browser. It is used to mark certs as CA certs when they cannot otherwise be determined as such (e.g., missing the basic constraints extension, etc.) The chain will be constructed properly if the intermediates are given no trust, which is the correct thing to do. -Ian
