[Fed-Talk] How does OS X choose which intermediate cert to use in chain?
[Fed-Talk] How does OS X choose which intermediate cert to use in chain?
- Subject: [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 11:29:19 -0500
- Acceptlanguage: en-US
- Thread-topic: How does OS X choose which intermediate cert to use in chain?
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?
Briefly: my OS X 10.8 keychain contains multiple certs with the CN "Federal Common Policy" -- 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. 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.
What makes OS X choose this bad Federal Common Policy cert over the good one that's in System Roots (and system and login -- I have three copies of the good one, all with custom trust settings saying Always Trust)?
(Of note, I'm happy to share the "bad" one with anyone who's interested -- it's interesting, in addition to the issuer difference described above, it has an expiration date in 2014 rather than the 2030 date of the current good one.)
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