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
- 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.
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>
|