Mike Smithwick wrote:
> 
> I have spent quite some time trying to figure out this signing biz,
> but it seems like the signtool docs are still stuck in Netscape 4 land
> and so are nearly useless.

Your questions are all about signtool.  signtool is a mozilla/NSS crypto
tool.  All the crypto heads who work on that stuff are over in
netscape.public.mozilla.crypto, so I'm cross posting this to that group,
and directing follow-ups to there.

Which signtool docs specifically are you referring to?  What URL?

> We were given a "p12" file from our CA. I assume that is by definition
> the certificate. 

A .p12 file contains a certificate and the corresponding private key.
It usually also contains the other certificates in the "chain" of certs
that verify your cert (but in your case apparently did not).

The fact that you got the .p12 file from someone else (didn't make it 
yourself) means that you are not the only person with a copy of the 
private key!  Therefore, you are not the only person who can sign objects
that appear to have been signed by the owner of that certificate you have.
That is undesirable for a certificate used for signing, in my opinion.

The usual method is that you generate the private key with your own browser
(be it Communicator 4, or mozilla or Netscape 7).  Your private signing key 
lives in the key3.db file, and is NOT normally sent to the CA.  You can put 
it into a .p12 file for your own backup or transferal purposes.  

> The docs mention exporting a p12 file, but never
> importing one, 

Right.  Because normally, you would _export_ it, having created the private
key yourself.  Having to import your private key seems quite unusual, 
unless you are transporting it from the system where you created it to 
another one.

> yet the Mozilla cert manager only permits importing a
> file. 

Is there a word missing there?  A <blank> file?  

mozilla does import .p12 files.  

> So I tried that, and our cert appeared in the list. From the
> docs it appeared as if Signtool then uses the two db files to get the
> info it needs: cert7.db and key3.db which I moved over to the
> directory that has my projects. 

Sounds good so far.

> (Pointing signtool to the original
> directory with the db files caused it to crash, probably the directory
> name was too long and overflowed some buffer).

Was your browser running at the time?  If you run signtool and point it at
the directory where the browser's DB files are kept while the browser is
running, bad things happen.

> Now I type in "signtool -l", and it both shows our certificate and the
> line "Error++ Unable to find issuer in certificate". 

Actually, it's:
    ++ Error ++ Unable to find issuer certificate

> I assume that
> means it cannot find a legal Verisign cert, but when I do a -L I
> clearly see that certificate as listed.

Was Verisign the CA that issued your cert?  
Did you get the .p12 file directly from Verisign?    

I'd guess that your cert was issued by some other CA, perhaps an 
"intermediate CA", whose cert was in turn issued by a "root CA", 
such as Verisign or some other root CA.  

In any case, apparently your cert DB doesn't contain the cert for the CA
who directly issued your cert.  IMO, that _should_ have been in the .p12
file.  You'll have to get the missing CA cert(s) into your cert DB somehow,
probably by downloading them from a server somewhere.  

All the certs in your cert chain mut be put into the signature for the 
jar file.  If you don't have all the certs in your cert DB, signtool can't
do that.

> I can create a temporary internal certificate and it works fine.

Your cert DB probably has the issuer CA cert for whatever CA you use
to issue that "temporary" cert, but not the CA cert for the CA from which
you got your .p12 file.

> what gives?

You might find it helpful to read through Netscape's 
"Introduction to Public Key Cryptography"
http://developer.netscape.com/docs/manuals/security/pkin/index.htm

Especially the sections entitled 
  "How CA Certificates Are Used to Establish Trust", 
  "CA Hierarchies", and 
  "Certificate Chains".

--
Nelson Bolyard               
Disclaimer:                  I speak for myself, not for Netscape

Reply via email to