Re: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
Re: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
- Subject: Re: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
- From: "Levine, Jason (NIH/NCI) [E]" <email@hidden>
- Date: Wed, 05 Dec 2012 13:35:37 -0500
- Acceptlanguage: en-US
- Thread-topic: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
On Dec 5, 2012, at 1:17 PM, "Miller, Timothy J." <email@hidden> wrote:
> On 12/5/12 10:29 AM, "Levine, Jason (NIH/NCI) [E]" <email@hidden>
> wrote:
>
>> Does anyone here know how OS X chooses which intermediate certificate it
>> uses when it's validating a certificate chain? Specifically, if a cert
>> has issuer "SuperSecure CA", and my keychain contains two different certs
>> with the CN "SuperSecure CA", what is OS X's methodology for choosing
>> which of these two certs is the proper issuer?
>
> There is only one proper issuer, and it's the one that has the same public
> key as identified in the signature.
Then to further clarify: both of the "Federal Common Policy" certs share the same public key. So OS X still needs to choose which is the "right" one to validate as the issuer.
>> Briefly: my OS X 10.8 keychain contains multiple certs with the CN
>> "Federal Common Policy"
>
> This should only happen if (1) they are different keys, or (2) they're
> stored in different keychains. E.g., I've got the Common Policy root
> (untrusted) in System, login, and the special "System Roots" keychains.
> All are the same cert.
I don't know what to say other than that it's happening. I have the "good" Federal Common Policy cert in all three keychains (login, System, System Roots), and then the "bad" one gets automatically added to my login keychain by Mail.app. This leaves me with four distinct cert entries -- login has good and bad, System has good, System Roots has good.
>> -- and due to Mail.app's behavior of auto-importing any certs it finds in
>> an email, and a sender which once included a signature cert chain which
>> has a "bad" Federal Common Policy cert in it, I keep getting this other
>> cert added to my keychain. This "bad" cert isn't self-signed like the
>> current Federal Common Policy cert, but rather was issued by "Federal
>> Bridge CA" and leads up to a CertiPath cert that has an "unrecognized
>> critical extension" and thus is untrusted by OS X.
>
> This is a different problem. Chain construction starts with the
> "suggested" path provided in the signed object (in this case, the mail
> message). If the sender includes a squirrely path (e.g., through FBCA to
> the Common Policy Root), then this path will be validated. Unfortunately
> CDSA will not try to discover a shorter path if this path validation
> fails.
>
> This problem usually originates with senders using Windows. Windows has
> an odd path construction behavior. Paths are selected based on a scoring
> algorithm, and the scoring prefers a (long) path that contains Name
> Constraints over a (short) path that does not. FBCA cross certificates
> all use Name Constraints.
But I can say that the problem isn't limited to Mail.app and its signed object. Yes, I can see how the fact that the signed object in Mail.app -- which contains the signer's cert as well as all eight certs upstream from it, including the "bad" Federal Common Policy cert -- provides the "suggested" path to validate, and how this validation fails. But unfortunately, once that "bad" cert is in my login keychain, then even apps like Safari choose it when validating SSL certs that claim issuance by Federal Common Policy -- I have screenshots that show this happening. And I can use OpenSSL s_client to dump the certs that are being sent by the SSL server and verify that it's NOT sending the bad certs nor suggesting a specific validation path.
So in the end, there's still something fishy going on -- OS X is using some algorithm to decide what the correct path is, and that algorithm is choosing an intermediate cert that's incorrect and causing validation failure.
Of note, the cause of the validation failure is that the "bad" Federal Common Policy cert is issued by "Federal Bridge CA" which is in turn issued by the unusable CertiPath cert; this led me to wonder whether there's an updated Federal Bridge CA cert that isn't dependent on CertiPath, and sure enough there is. Installing THIS Federal Bridge CA cert has resolved the issue… but I'd note that it resolved it due to the same unknown algorithmic choice that OS X is making to decide that my newer Federal Bridge CA cert is the right one to choose as the issuer for the "bad" common policy cert.
>> Once this "bad" Federal Common Policy is added to my keychain, OS X
>> immediately chooses it as the issuer up the chain for ALL Federal PKI
>> certs -- meaning most of the SSL certs at the NIH, all the certs on PIV
>> cards, etc. -- and stops trusting all of these. Each time, I have to go
>> into the keychain, delete this rogue Federal Common Policy cert, and then
>> be OK until the next time Mail.app caches the email that has that "bad"
>> cert.
>
> Don't delete the CP root cert. Edit the cert's trust setting to
> "Untrusted" for all users and the problem will (mostly) go away. You
> don't need the CP root anyway (it no longer anchors any end-entity paths).
Interesting -- I will test this later. It'll have to involve backing out my newer Federal Bridge CA cert so I can see what's going on…
JAson
_______________________________________________
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