Loren wrote: > "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message >news:<[EMAIL PROTECTED]>... > >>You said your cert shows up when you list certs using the -L option. >>Do they show up when you list certs using the -l option, which lists certs >>that are allowed to sign objects? > > > OK, we are getting somewhere :) > > when using -l option, I found that the signtool will choke on some > of my cert extension, since it complains on finding the issuer of my > object signing cert. I then use certutil to parse the cert and found > that the victim's authority key identifier extension contains some > funny characters in it, seems that the extension is not well > recognized by certutil (and presumably signtool).
The extension is recognized. Those "funny characters" should be values that point to the issuing certificate. I think what you have run into is that older version of NSS (including those in Communicator) were very forgiving in intrepreting the authority key identifier extension. Strictly speaking, if the certificate has that extension, and no certificate has a matching subject key identifier (or issuer/serial), then it is not possible to forge the next link in the chain. However, older versions of NSS would throw out the authority key identifier extension if a match was not found, and then use the issuer DN of the subject cert to locate the issuer. Depending on how you look at it, this behavior was neither incorrect nor correct. In some cases, it would lead to an incorrect chain (it would accept an issuer whose subject key identifier was _different_ than the authority key identifier of the subject cert!). But in other cases, it would allow more flexibility than the PKIX specifications, and many real-world certificates rely on this flexibility. In NSS 3.6, we cleaned up the handling of the identifier extensions, reintroducing some of the flexibility of older NSS versions, while (hopefully) correcting any mistakes. In the interim, you will probably find that the version of signtool that shipped with NSS 3.3.2 will work with your chain. > Then I reissue the whole chain and put only basicConstraints > (non-critical) in CA certs, while the user cert got basicConstraints > and nsCertType. From the PSM Manage Certificates dialog, eveything > looks good, from certutil, it can read all the certs and extensions. > but using signtool -l, it spits out the obj signing cert with : > ================================================================= > using certificate directory: . > > Object signing certificates > --------------------------------------- > Loren test obj sign cert 2 > Issued by: Object Signing User Certification Authority 1 - ABC > Company (Object Signing User Certification Authority 1) > Expires: Sat Oct 11, 2003 > ++ Error ++ THIS CERTIFICATE IS NOT VALID (bad signature) > --------------------------------------- > For a list including CA's, use "signtool -L" > ================================================================= > > I suspect it is the signtool can't recognize the extension encoding > of Mozilla's db, but it understands Communicator's. The extension encodings are identical, and have nothing to do with Mozilla or Communicator. I suspect there is something wrong with the way the certs were generated (it would appear the wrong key was used to verify the cert). How did you rebuild the chain? -Ian
