On Tuesday, August 15, 2006 11:07:41 AM UTC+5:30, Nelson B wrote: > David, > > As you've already discovered, there's not much difference between the > certs being in the cert db versus the certs being in the root certs module. > They're just two somewhat different ways to hold certs and their related > trust flags. While you're working out the detail, I suggest you keep on > using the cert DB, and when you get it all worked out, then consider using > the root certs module. > > (BTW, you've apparently figured out how to use the root certs module. > Congratulations on that.) > > Calling CERT_GetDefaultCertDB is a fine way to get the value you need > for that function. It's not causing your problem. > > There are two ways you can get SEC_ERROR_UNKNOWN_ISSUER. You can get that > error when the cert code is trying to reconstruct the chain of certs for > the cert you're trying to verify. Then, if that succeeds, and you have > OCSP configured, (and the cert has the right extension for OCSP), the code > may attempt an OCSP check, which involves constructing a cert chain for > the OCSP server. That's the second way to get the error, failing to > reconstruct the cert chain for the OCSP responder. > > The single most crucial aspect of finding the issuer of a certificate is > that the "Issuer name" in the issued cert must exactly match the "Subject > Name" in the issuer's cert. The entire name must match exactly, in every > part, in every detail, in the binary encoded form. That means that if > the (say) common name is in ASCII in the issued cert's Issuer name, then > it must be in ASCII in the issuer cert's subject name. It can't be in > ASCII in one place and UTF8 in the other. The components of the name must > be in the same order. The names are case sensitive. Punctuation matters. > > So if you have two certs, and you think one of them is the issuer for the > other, the first thing to do is to compare the two cert names in printable > form, to see if they match in every detail. If they do, then look at them > in their binary forms, to be doubly sure they match in every detail. > If you find that they don't match in any detail, then the only solution is > to get the subordinate cert reissued so that it's issuer name matches > exactly. > > Once you know those names match exactly There are a number of other things > to check. > > 1. The issuer cert must be a CA cert. It must have a "basic constraints" > extension that says it is a CA cert. > > 2. The issued cert may have one or more extensions that contain additional > information that must be present in the issuer's certificate in order for > the issuer's cert to be considered the real issuer. > > For example, the issued cert may contain an "Authority Key ID" extension > that contains the Issuer name and the Serial Number in the CA cert. Note > that that's the issuer name in the issuer's cert, not the subject name in > the issuer's cert. And its' the serial number in the issuer's cert. > If your issued cert has that extension, and your issuer cert doesn't match > that info, then NSS will rightfully decide that it has the wrong issuer cert. > > Similarly, the issued cert may contain an authority key ID extension with a > Key ID in it. In that case, the issuer's cert must have an extension called > a "Subject Key ID" and the two Key IDs must match. > > When NSS has verified one certificate against the cert of its issuer, it > repeats the check, using the issuer certificate as the issued cert. It > keeps doing this until it either (a) finds a bad signature or (b) can't > find the issuer cert, or (c) finds an issuer cert that is marked as trusted > for the purpose for which you're testing (e.g. SSL server). If it doesn't > find any of those, it's likely to report the error you received. > > It's possible to mark an EE cert as trusted, skipping all the CA checks. > That requires the "trusted Peer" bit (P, not C). > > It's kind of unusual to put an EE cert into the relying party's cert DB, > and especially unusual to put an EE cert into the root cert list. It makes > dealing with expired/renewed certs just slightly trickier. But it should > work in principle. > > -- > Nelson B
@David, @Nelson How to use the root certs module? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto