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 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
