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: "Miller, Timothy J." <email@hidden>
- Date: Wed, 05 Dec 2012 18:17:13 +0000
- Thread-topic: [Fed-Talk] How does OS X choose which intermediate cert to use in chain?
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.
>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.
>-- 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.
>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).
-- T
_______________________________________________
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