"Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Loren wrote:
>
Thank you for your answer, but after I double checked the
certificates, I don't see any of the problems listed here, please see
the following comments:
>
> Many people who use OpenSSL as a CA create certs or cert chains that
> violate the rules for X.509 certs. Examples of very common mistakes
> include:
>
> 1. Reusing serial numbers. No valid CA will ever issue two certs with
> the same issuer name and serial number. NSS relies on this fact.
> If you try to add a cert to your cert DB that has the same issuer name
> and serial number as another cert already in the DB, the new cert will
> not be added.
I only import 3 certs here, root CA, users CA, and an end user cert.
root CA is self-signed, and user CA is signed by root, they have
serial number 0 and 0x11, respectively, and user cert is signed by
user CA, so there is no serial number reuse.
>
> 2. Using the same subject DN for the CA cert and for one or more server
> certs or email certs issued by that CA. A server cert that has the same
> subject name as the root CA cert that issued it will have the same name
> listed as both Subject and Issuer, making it appear to be self-issued.
>
as noted above, these 3 certs did have their own DN, specifically, one
is called Generic Root CA for CN, the other CA is Class 1 CA, and end
user is my first name, Loren.
However, I did notice some points, I imported these cert as pkcs12
file, and the certs/keys looks good when I browser them in
Edit->Preferences->Privacy & Security -> Manage Certificate, however,
when I use 'signtool -d "path to db" -L', it only lists the three
certs I imported, without all the other CA certs (Verisign, for
example) that are default in the db.
Then I try to fire 'signtool -d "path to db" -k "my cert" -Z
signed.jar signdir', it will fail with :
signtool: the cert "my cert" does not exist in the database: Problem
with database
the tree "signdir" was NOT SUCCESSFULLY SIGNED
What I suspected is the certificate extensions could be the
problem, currently I add following to end user cert:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME, Object Signing
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Netscape Comment:
ABC Enterprise Object Signing Certificate
X509v3 Subject Key Identifier:
*snipped*
X509v3 Authority Key Identifier:
*snipped*
X509v3 Subject Alternative Name:
*snipped*
None of them are critical, I don't know if signtool will choke on
any one of them? Any ideas?
Regards,
Loren
> I'd guess that your mozilla DB already had a cert in it with the same
> subject name or the same issuer and serial number as the cert you tried
> to add to it, but the Communicator DBs did not already have such a cert
> in them. In that case, the issue is not a version-based incompatiblity
> but rather a set of certs already in a particular DB that preclude the
> addition of (or finding of) your new cert in the DB.
