No, this has to do with a change in the way MacOS is handling client certs as a result of a perceived security risk: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1580
The new behavior is as follows: 1) If a server requires client cert verification, then Safari prompts the user to select an appropriate cert from they local cert store (keychain). If the user does not have a cert, the SSL Handshake fails and the connection is never built. This is a problem since our CAS login process allows the user to failback to username/password auth if a cert is not available, and not everyone has a cert available at all times. 2) If client cert verification is optional, Safari will not send a certificate unless you specify a preference in the keychain instructing it to do so. The problem with this method is that you must provide a specific URL in the preference. In otherwords, https://login.example.com/cas/login?service=XYZ and https://login.example.com/cas/login?service=ABC are considered two separate URLs, and there's no apparent way to do wildcarding. In our environment, there's not a single common entry point into the single sign-on process -- users potentially enter from any given number of CASified URLs. The problem here is obvious. Even if we could gather all the possible urls, or even a sample of the most common ones, there's no way the user would sit and enter who-knows-how-many preferences. ..Sean. Shi Yusen wrote: > Do you mean you want to use multiple CRLs? > > > > 在 2008-06-10二的 12:23 -0400，Sean R. McNamara写道： > >> Hi, >> >> I posted a message about this last week but didn't hear anything back >> from anyone. As of OS X 10.5.3, Apple changed the way client certs are >> released. In the case that a [apache] server is configured with >> >> SSLVerifyClient optional >> >> you must specify an option on your client cert in the keychain to allow that >> cert to be released to that particular requesting server. (in this >> case, our CAS server) >> The problem is you cannot specify wildcards in the option, and it considers >> URL parameters as part of the fixed URL. >> >> The end result is that CAS x509 auth breaks unless you were to explicitly >> specify every single possible entry point (i.e. every possible value >> of the 'service' parameter), which isn't pretty for larger deployments. >> >> Of course you can set SSLVerifyClient required, but this precludes anyone >> from doing any other form of authentication if they don't have a >> client cert since the SSL Handshake will fail and then, game over. >> >> It's a catch 22 either way. Has anyone else encountered this problem? >> If so, has anyone come up with any possible solutions? >> >> I appreciate any help or advice that could be provided.. >> >> Thanks.. >> >> ..Sean. >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
