David Stutzman wrote:
> Nelson B wrote:
>> But neither of these flags, whether missing when desired or present when
>> unwanted, should cause the error you were experiencing, -8179.
>
> The missing c (or C) is exactly what was causing the problem. I had
> originally added all my CAs using "C,C,C" but then I realized it
> probably wasn't checking the whole chain because the verify algorithm
> short circuits if it gets an explicitly trusted cert. I traced the
> -8179 error to a spot in the code where it calls a function named
> something like FindIssuer and that function returned NULL basically when
> it SHOULD have found the intermediate CA that *was* in the built-ins
> module. I imagine that it ignored the intermediate CA certificate
> because when it was looking through its big list of certificate
> candidates it didn't find one that had either c (valid CA) or C (trusted
> CA), it only found certificates marked as peers so it ignored them and
> hence "unkown issuer". That's just my take on the issue from rifling
> through the code.
Thanks for the report. Sounds like something is amiss with the handling
of the valid_ca flag ("c"). That flag is supposed to be an override,
telling NSS that "this is a valid (not necessarily trusted) CA cert, even
if it doesn't look like one because the Basic Constraints extension is
missing or improper". It was originally intended to allow X509v1 and v2
certs (which have no extensions) to be able to be used as CA certs.
It shortcuts some of the CA cert validity checks, but not all. It doesn't
imply that the cert is a trust anchor. Trusted CA ("C") does that.
That trust flag shouldn't be necessary on any properly constructed X509v3
cert with the proper BasicConstraints extension, but apparently it has
become necessary. This code apparently needs re-examination.
--
Nelson B
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
