Re: [Fed-Talk] Keychain Access locks up when I try to change trust settings for a certificate
Re: [Fed-Talk] Keychain Access locks up when I try to change trust settings for a certificate
- Subject: Re: [Fed-Talk] Keychain Access locks up when I try to change trust settings for a certificate
- From: "Miller, Timothy J." <email@hidden>
- Date: Wed, 26 May 2010 09:23:14 -0400
- Acceptlanguage: en-US
- Thread-topic: [Fed-Talk] Keychain Access locks up when I try to change trust settings for a certificate
On May 26, 2010, at 6:18 AM, Ron Broersma wrote:
> Michael,
>
> You appear to be suffering from the certificate cancer that is spreading. The problem is that there are 2 certificates with the same name "DoD Root CA 2", one of which is the real Root CA 2 (expires in 2029), and the other (expires in 2011) is an intermediate cert signed by "DoD Interoperability Root CA 1". Having 2 important certs with the same common name was a REALLY BAD IDEA on someone's part. A number of applications appear to build their certificate chain based on just the common name rather than other attributes, and therefore will often choose the wrong one. I know that both Thunderbird and Entourage suffer from this.
This has nothing to do with the distinguished name. This is a trust problem.
A validation engine builds a path from end-entity certificate to a trust anchor key. What you're seeing (and Michael is experiencing) is the system building the path from the end-entity cert to the DST ACES CA X6 trusted root through the Federal PKI Bridge CA. The DoD Root 2 certificate in this chain is *not* a root certificate, it's a cross certificate issued *to* the DoD Root 2 CA from the DoD Interoperability root (Apple presents root certificates with a gold border, which you'll note is missing in your screen shot).
Since certificate subject names must identify the entity to which it is issued, a cross certificate *always* uses the same name as the self-signed certificate the CA issues to itself.
(Any validation engine that uses only the common name to build a chain is in violation of both the RFC and X.509 and must be fixed. But that's not what's happening here--see below.)
> For example, I can see that your email is signed, but uses the wrong DoD Root CA 2, and therefore you have the cancer...
This is almost the right question. The chain you depict *should* have terminated at the DoD Root CA 2 self-signed root, which is included with OS X and has default system-wide trust. This is the shortest path to a trust anchor, so is supposed to be preferred by the validation engine (IOW, it makes no sense to look for a longer chain when a shorter chain satisfies the same requirement). So the right question is, why didn't the system build the chain to the DoD Root CA 2 trust anchor?
There could be multiple reasons for this:
(1) The system doesn't have the DoD Root 2 CA certificate installed. Since this CA certificate ships with OS X, it means someone would have had to remove it.
(2) The system doesn't *trust* the DoD Root 2 CA self-signed certificate. Since the system by default includes this CA in the system trust list, someone would have had to change this.
(3) The validation engine is being instructed to ignore the DoD Root CA 2 trust anchor, and chaining over the bridge is the only other path to a trust anchor available.
Of these, (3) is most likely. This can in fact happens if an application is relying on a partial chain delivered along with the signed object. E.g., if the S/MIME email you receive contains the signing cert, the DoD issuing CA, and the *cross certificate for DoD Root CA 2*, then the validation engine *may* start with that partial path instead of building the chain from the beginning. This will lead the chaining engine to build paths across the bridge looking for a trust anchor rather than to the DoD Root CA 2 trust anchor.
This is a problem at the *sender's* side. They should *not* be sending the cross-certificate *under any circumstances.* We know Outlook will do this under certain circumstances when the DoD Interoperability Root CA is installed improperly on the workstation, which is why in the AF we explicitly limit installation of that root unless there's an overriding need.
> If you have the wrong chain, then your signature cannot be validated.
Actually, the reason it's not validated in the example you provide is because OS X can't process a critical certificate extension; that's why this path is invalid. Very likely the offending extension is the name constraints extension in the cross certificate from the FBCA to the DoD Interoperability Root CA, but I'd have to examine the current cross-certs to be sure.
> If you delete all the bad certs out of keychain, things start working better. Unfortunately, the minute you open an email from someone that has the cancer, you will be re-infected and the bad certs will reappear in your keychain. Each time that happens, you need to delete them out of keychain again.
And here's where you hit on the real problem. The *email you're receiving* is providing an improper partial chain, as I explained above. That's why Mail & Entourage keep reaping the certificates again after you delete them. You'd be better served to mark the DoD Interoperability Root certificate as untrusted in Keychain Access; this should prevent the system from using that validation path, and prevent it from re-collecting the certificate each time you receive an email.
-- Tim
_______________________________________________
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