Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
- Subject: Re: [Fed-Talk] Change in Cert Validation in 10.6.4?
- From: "Henry B. Hotz" <email@hidden>
- Date: Tue, 29 Jun 2010 13:18:45 -0700
At this point my own testing/experimentation has muddied the waters on my machine too much. Thanks for telling me how it was originally supposed to work. Maybe I can get back to that (and get back to being able to use my certs).
I will just remind people that I got a chain that leads to a trusted root, and the problem was that Apple doesn't support a "MUST support" extension in one of the certificates. An ancillary problem is that there wasn't a good enough failure recovery to discover that there was another path to the same trusted root. Both of these seem like complaints to make to Apple.
On the US Gov't side I wish that the whole PKI infrastructure weren't so complex. While I don't see a specific flaw here, it seems like we're asking for trouble.
*sigh*
On Jun 29, 2010, at 11:52 AM, Disiena, Ridley J. (GRC-VO00)[DB Consulting Group, Inc.] wrote:
> Henry,
>
> This is not a fix, but as a work around for the long chaining with the errors, try this:
>
> • Delete all NASA NOCA certificates issued by the Treasury Root CA in all keychains
> • Make sure you have the NOCA certificates issued by Common Policy in either the System or Login keychain
> • Download the NOCA certificates from here: https://pki.treas.gov/noca_ee_aia.p7b
> • If you import them all, go back and delete the Treasury issued certificates that are in that bundle.
> • In any keychains, delete any Common Policy Cross Certificates, possibly any FBCA Cross Certificates if they try to make the NASA issued certificate evaluation go to Treasury Root.
>
> The chain should be from the NASA identity certificate to the NOCA Certificate issued by Common Policy, to the Common Policy Root Certificate in the "System Root" Keychain.
>
> From my experience, if there are any NOCA certificates issued by Treasury, OS X will go down that path when evaluating. In the absence of the Treasury issued NOCA certificates, it will go down the Common Policy path. Also, it will go down even more paths as you have seen in the presence of cross-certificates. I have not found the OS X logic for what it chooses to use when evaluating if in the presence of many possible paths, but it does not choose the best or shortest possible path as we can clearly see.
>
> I have to give Shawn Geddis credit for pointing out that the built in System Root can be leveraged, but this only works if its the only path from what I have seen.
>
> There still is a problem especially when applications and emails keep bringing the other certificates back into the keychains that introduce the alternate paths that get chosen first by OS X when evaluating.
>
> Here is an example of the simple chaining to the Common Policy Root already in OS X.
>
> <Screen shot 2010-06-29 at 2.33.41 PM.png>
>
> Ridley DiSiena
> Emerging Technology and Desktop Standards (ETADS)
> Desktop Smartcard Integration / ICAM Engineering
>
>
> On Jun 28, 2010, at 7:36 PM, Henry B. Hotz wrote:
>
>> I now get the following error when I receive an encrypted email from someone else at NASA. It doesn't prevent me from actually reading the email, but I don't recall getting this warning before.
>>
>> Looking through the cert I see a critical "name constraints" extension (OID 2.5.29.30) which seems the most likely suspect, but I may be wrong. Even if I check the "always trust" box on the FBCA, the "common policy" cert still fails because it has an invalid issuer.
>>
>> Any comments or analysis anyone?
>>
>> <PastedGraphic-3.tiff><ATT00001..txt><ATT00002..txt>
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden