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.
