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,," ) - 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? 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?
And about the trsut for a root CA: A root CA may only issue intermediate CAs. 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"?? 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)? 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?? -- P "Nelson Bolyard" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Patrick wrote: > > > I have an NSS app that works with a known PKI. I know what the Root CAs are, > > and what the intermediate CAs are. If a sender in an SSL connection is > > > I assume you mean "if a server ..." > > > > expected to send the subject cert, and any intermediate CA certs needed to > > link the subject cert to the trusted root, why even bother keeping > > intermediate CAs in the apps cert db? Is the reason that an SSL sender *may > > not* send the whole cert chain, in which case the verifier can still do the > > verification if intermediate cert exists in my app's cert db? > > > The SSL and TLS specs require each side that sends a cert to also send the > chain, including any and all relevant intermediate CA certs. Each is > permitted but not required, to send the root CA cert, because the recipient > is presumed to already possess a copy. Most servers send the root CA cert > in the chain, if I'm not mistaken. > > But there are MANY SSL servers out there in the world, mostly running Apache > and somebody-or-other's SSL code, that have been misconfigured by their > administrators, so that they do not send the intermediate CA certs. > A client that already has a copy of the intermediate CA cert stored > somewhere works with such a server, and a client that has no copy of the > intermediate CA cert doesn't. When the most widely deployed and used SSL > client in the world works with those broken servers, people say that any > other client stinks if it doesn't work with them. (sigh) > > > > Should my app flag such intermediate cert in the cert db as "Valid CA" ( > > trust flags = "c,," ) ? > > > No, shouldn't be neccessary. As long as the root is known and trusted, > there is no need to separately trust any subordinate certs. > > > > Should my app flag a root CA as "Trusted CA to issue client certs" and " > > Trusted CA to only server certs" (trust flags = "CT,,")? > > > The trust flags for a root CA should be appropriate for the actual and > intended uses of that CA. If the CA exists expressly for issueing server > certs, and not client certs, or vice versa, then the trust flags should > reflect that. > > > > And what does the "C" trust flag mean exactly? I.e., what does "Trusted CA > > to certs (only server certs for ssl)" mean? I understand it to mean > > "Trusted CA to issue server certs"... > > > Where do you see the string "Trusted CA to certs (only server certs for ssl)"?? > I don't think I've seen that before. certutil says > > T trusted CA to issue client certs (implies c) > C trusted CA to issue server certs (implies c) > > As you know, in NSS there are 3 sets of trust flags for a cert, which > are: SSL, email, and "object signing" (where "object" means "JAR file", > more or less). Generally "C" means "cert is trusted as a CA to issue > certs for this purpose". IMO, there should have been 4 (or more) sets, > with "SSL client authentication" and "SSL server authentication and key > exchange" being separate sets, and "C" being equally meaningful for each set. > > But instead, there is just one SSL set, and in it "C" means "CA is trusted > to issue SSL server certs", and there is a separate flag "T" which means > "CA is trusted to issue SSL client certs." AFAIK, the "T" flag is > meaningless in the email and object signing sets, so CT,CT,CT means the > same as CT,C,C. > > /Nelson > Speaking only for myself. >
