Thanks very much for the exposition and advice. I _think_ I have
a better understanding of the issues, but have a couple of
lingering questions.
On 10/13/08 at 8:01 PM, email@hidden (Ken McLeod) wrote:
First off, if this is new code being written for 10.4+, I would
try to use SFCertificateTrustPanel instead. SecEditTrust() is
part of a frozen, dusty SecurityHI bridge layer to support
Carbon access to native Cocoa UI.
Unfortunately, the app in which I'm writing this is a dusty
Carbon app. :-) Can I still call the code in
SecurityInterface.h, possibly using something like the following:
if (NSOKButton == [panel runModalForTrust ...])
{
/*...*/
}
Or should I stick to calling SecEditTrust()?
(I guess I can try it and see if it works, but I'd still
appreciate knowing whether it's the supported way to go.)
One problem with your code is that you are treating
kSecTrustResultUnspecified as an untrusted case. In fact, it's the one
case that means the certificate *is* trusted, all by itself, without
user trust settings having been specified. (If user trust settings
were specified, then you get a kSecTrustResultProceed or
kSecTrustResultDeny result instead.)
Here's how you should group the SecTrustEvaluate result cases:
Excellent, thank you very much for that correction.
The "2 attempts to get a certificate marked as trusted" issue is a
known Leopard bug, which is fixed in an upcoming 10.5.x update.
OK, thanks. I suppose I should test on 10.4.x, but before I
invest in that, do you know whether there are any considerations
to using SFCertificateTrustPanel or SecEditTrust() on 10.4.x?
(You're evidently running Leopard since you are seeing the blue "+"
badge, indicating that there are user trust settings on this
certificate. On Tiger, user trust settings are advisory only... you
can check them yourself with SecTrustGetUserTrust if you get a
kSecTrustResultRecoverableTrustFailure result, but they do *not*
affect the outcome of a SecTrustEvaluate call as they will on Leopard.)
That is also extremely helpful, thank you for that bit of
detail. I will make sure I account for that when running on
10.4. Sorry that I omitted the detail of which OS I was running;
you are correct and I am running 10.5.5 with the latest public updates.
Despite all of this, however, the decisions I make in the dialogs
don't stick: [...]
You've likely encountered a bug. Almost all of the "trust settings
don't stick" bug reports we've seen fall into two groups:
1. If more than one app is running and has changed trust settings via
this UI in a given login session, one of them may have grabbed a lock
on the helper tool (kcproxy) which is used to change the trust
settings. If you see messages in your syslog which say, "Couldn't
register server "com.apple.KeychainProxyServer" on this host" then you
are hitting this bug. The workaround is to quit any other apps which
have put up the trust UI, then try again.
I have in fact seen the "couldn't register server" message that
you mention. It's possible that Safari previously presented the
trust UI for an entirely different reason, so I will try
quitting it and see if that restores normal behavior.
What's the presence of this bug as it relate to OS versions?
Does it occur only on 10.5 as well, or will it be found on 10.4?
And what's the prognosis for a fix, or is there any workaround?
2. If your mail server is hosting more than one virtual domain (and
does not present a separate certificate for each), such that
successive connections to "mail.example.com" and
"mail.another-different-example.com" both resolve to the same server
presenting the same certificate for "example.com", then there is a
known bug where clicking the "Always trust <certificate> when
connecting to <host>" checkbox will overwrite previous trust settings
for that certificate with the current value of <host>, instead of
appending it.
I haven't run into this one, but will keep an eye out.
Note that the "always trust" checkbox has a couple of behaviors. [...]
Since "add certificate to keychain" and "change trust settings on
certificate" are separate operations, they may each require
authentication. (We've mostly got that down to just one dialog now.)
OK, that explains the multiple authentication dialogs; thank you.
You can use the /usr/bin/security tool to dump a list of your current
trust settings (on Leopard and later). [...]
Excellent. I will use this to help reconcile what I'm seeing
with the stored state of the cert. :-)
Someday I'll look back on all this and laugh... until they
sedate me.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
