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

Reply via email to