[EMAIL PROTECTED] wrote: > Sorry if this has already been answered, I searched for an answer > before asking. > > 1. What should be trust args for a self-signed certifcate, that needs > to be used as a server cert? Should that be valid peer or trusted peer?
or both? Those are separate flags, not mutually exclusive. Definitely will need trust. May also need validity override. > Can self-signed cert be used with NSS for server authentication? Yes, if the client explicitly trusts the server's cert, and the cert is not otherwise invalid. EVERY client that is going to honor the server's self signed cert will need to have a copy of it, and have marked that copy trusted. > 2. What is the difference between valid peer and trusted peer? To be used, a peer's cert needs to be valid and NSS has to know that you (the relying party) trust it, or its issuer, for the purpose for which it will be used. Trust is usually inherited from the cert's issuer (or its issuer's issuer). That is, usually you (relying party) don't mark each and every server's cert as individually trusted. Instead you mark certain issuer's certs as trusted for certain uses, and the certs issued by those issuers inherit the trust that you gave to their issuer. For example, when you've trusted a CA to issue SSL server certs, the certs it issues will generally inherit the trust to be used as SSL server certs, provided that their heritage can be proven (issuer's signature can be verified). The "valid peer" flag is an override, saying "treat this cert as valid, even if it appears not to be". This overrides certain specific issues that may arise within a cert. It does not override expiration dates, IIRC. The "trusted peer" flag means "treat this cert as trusted, even if trust cannot be inherited from its issuer." Self signed certs cannot be used unless they have the "trusted peer" or "trusted CA" flag set (depending on the purpose for which they're being used). > Is there any doc or notes out there describing how to use these trust flags There is some and needs to be more. > 3. What is the relationship between trust flags and extensions in the > certificate? Nothing in the cert (including the extensions) can impute trust. Nothing in the cert can, by itself, make you believe it. A cert is a signed assertion, an assertion made by the signer, asserting a relationship between the subject name in the cert and the subject public key info in the cert. The extensions in the cert are limitations on the assertion, limitations made by the signer. The cert says, in effect, "I <signer> assert that <subject name> holds the private key corresponding to this public key (with all that that implies), and that this public key is usable ONLY for the purposes named by these extensions." As the person receiving the cert, being asked to believe it, you either a) have already decided to trust the signer of the cert, and therefore (assuming you can validate the cert's signature as belonging to someone you trust) you believe what the cert says (and accept its limitations), or b) you yourself choose to believe the relationship (between name and key) asserted in the cert, even if you don't trust (or even know) the issuer, or c) you treat the cert contents as lies, and do not honor their assertions. The trust flags serve to a) tell NSS which CAs (issuers) you've chosen to trust, and b) tell NSS which certs you've chosen to honor, and for what purposes you've chosen to honor them, even if they don't come from issuers you trust. > If the certificate can itself describe it's type and usage, is there a > need for trust flags? Yes. Here's the reasoning. Ask yourself these questions: Do you want to believe every cert that is ever presented to you? Will you believe every such cert, and accept it at face value? Are you willing to believe that a cert really is your bank's cert, even if it was just made up by Evil Eve, your neighbor next door? :) Is there anything your neighbor can put into the cert that will make you believe that its public key really is the bank's key? If you've chosen to exercise discretion on certs, if there are some certs that you are going to honor, and some that you are not, how will your browser know which are which? The answer involves trust flags. > 4. I understand that trust flags are unique to NSS Yes, and no. The particular form and names of NSS's trust flags are unique to NSS. But every sensible PKI system has something that serves the same purpose. NSS puts all certs together in a single common store, and uses flag bits to keep track of what each is good for (if anything). Windows has separate stores for certs of different types. In each store, it has a way to specify the trusted purposes for a cert, but its trust info is stored as large multi-art numbers called "object identifiers" or OIDs, not as flag bits. The trust OIDs in windows store can be changed, just as the trust flags in NSS can be set. So, conceptually, the two product's stores are very similar. Neither one asks its user to blindly accept a cert on face value, AFAIK. Both remember the user's choices as additional info stored with the certs. The use of OIDs is very flexible and extensible. NSS's flag bits predate many of the OIDs now in use. NSS was in use before many of those OIDs were created. Perhaps if we were going to rewrite NSS now, we'd use OIDs for trust flags, too. > and doesn't actually change the certificate, by that I mean, if I were to > export the certificate from the key store that had its trust args mofified, > the certificate type or extensions would be same as the original cert > imported into keystore. True. The cert is a digitally signed document. Any change to it would invalidate the signature and make it useless. The same thing is true of Windows' cert store. You can change the trust OIDs stored with a cert, but doing so doesn't actually change the cert itself. > 5. This may be a question to the product that uses NSS than on NSS. > I changed the "SSL group" of trust args to blank and started this > software (from Sun) which uses NSS, it started SSL enabled with > that cert. Is that OK or a bug? Trust flags are mostly relevant to "relying parties", that is, to people (and their products) who receive a cert from someone else (e.g. over a network), and who need to decide if they believe those certs or not. So, the trust flags are mostly relevant to the recipients of certs, not the senders of certs. I'm guessing you started a server product. Let's say it was an https server. The server sends out its cert(s) to remote clients. The clients need trust flags to decide if they trust those certs. The server itself doesn't need trust flags to send the certs out. You configure the server, telling it which cert (chain) to send out. It doesn't need trust info, beyond the fact that you (its master) have told it what to do. That's all trust flags are: orders from the master. So, you've created a self-signed server cert. Now, you've discovered that to make it useful, you don't just set trust in the server's store. You must set trust for that cert in *EVERY* CLIENT's store. Every mozilla client, every IE client, *every* client. What a hassle! That's why using certs from widely known and trusted CAs makes economic sense. It avoids the cost of having to find and configure each and every client that will ever use your server, downloading your server's cert onto that client, and telling your client to trust your server's cert. (We call that: full employment for the help desk! :) > Sorry for the long list of questions, had to get the basics right and > hopefuly will help others looking for similar answers. You bet. That's the idea of these newsgroups and mailing lists. > Thanks > SN -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
