About certutil and how it does say "Trusted CA to certs (only server certs for ssl)" when I use it against my cert7.db: I use the regular command-line arg to see this output, i.e., "certutil -L -d c:\mycertdbdir", where mycertdbdir is the directory where my cert7.db lives.
As I said this cert7.db I've had for a while. I may have been created with NSS3.1. Could that explain the different certutil output? -- P "Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Patrick wrote: > > > > Ok thanks. > > > > About trust flags: > > What if I do keep the intermediate CAs in my apps' cert db and I do flag > > them as "Valid CA" (trust flags = "c,," ) > > There's no need to give them any trust flags at all. "c" is a trust flag. > > > - With the understanding that I don't need to trust them in my cert db as > > long as the root is trusted. I figure that as long as a CA is in the cert > > db, and it's not a root CA, I'd flag it as valid -, what does "Valid CA" > > mean exactly? > > It means that the cert is a CA cert, even if it doesn't appear to be. > It is an override. It means that the cert should be treated as a valid CA > cert, even if it doesn't appear to be a CA cert at all. It does not imply > that the cert is absolutely trusted, however. A cert flagged with "c" is one > that is valid for the purpose - provided that it is subordinate to another cert > that is absolutely trusted. It's really only relevant to intermediate CA certs > that don't appear to be valid on their faces (e.g. because they are missing the > "basicConstraints" extension). An ordinary properly formatted intermediate CA > cert doesn't need it. > > > Does NSS perform the cert chain verification differently if an intermediate > > CA is marked as a "Valid CA"? E.g., Does NSS skip any of the signature > > checking on CA certs? > > AFAIK, it doesn't skip any signature checks. It merely skips the checks that > determine that the cert is a CA cert (as opposed to being a leaf (non-CA) cert). > > If you have (say) an SSL client auth cert, and you use your cert to issue/sign > an SSL client auth cert for some other user, attempts to do SSL client auth > with the cert you issued would ordinarily fail because your SSL client auth > cert is not a CA cert. Setting the "c" flag on your cert would cause NSS to > treat your cert as if it was an intermediate CA cert. So, that if the CA that > issued your client auth cert was trusted to issue SSL client auth certs, then > the cert you issued would also be trusted. > > > And about the trsut for a root CA: > > A root CA may only issue intermediate CAs. > > That's not generally true. Generally, a CA (root or intermediate) can issue > leaf certs or subordinate intermediate CA certs. The latter is limited by the > path length constraint (if present) from the root CA's cert. > > ? So really flagging it as "Trusted > > CA for client/server certs" does not really fit... > > Maybe there should be a flag for "Trusted to issue intermediate CA cert"?? > > If a root CA is trusted to issue client auth certs, then client auth certs > issued by that CA or any of its subordinate CAs are trusted. > > > About cert7.db: > > Is the cert7.db format here to stay as the storage place for certs in NSS? > > Is there talk about using the key/cert store formats likethe ones used by > > Sun's java tools (ie, the standard JCA KeyStore)? > > NSS may move to another format in some release, but I doubt it will be a Java > format. JSS may have a requirement for JCA compliance, but NSS does not, IMO. > > > Finally, about certutil: > > It does say "Trusted CA to certs (only server certs for ssl)" when I use it > > against my cert7.db. This cert7.db I've had for a while. I may have been > > created with NSS3.1. WHat that explain the different certutil output?? > > What command line arguments do you use to see that message? > > > -- P > > -- > Nelson Bolyard > Disclaimer: I speak for myself, not for Netscape
