I guess it's not only Safari has this behavior. There's a way you can try to resolve this problem: use a logon applet. When the applet (in client) finds any certificate(s) in web browser, prompts select a certificate to login.
When no certificate(s), prompts username/password. Perhaps you can try the OpenLogon applet in OpenOCES. It's for digital signature. The pros are: You can make the users happy. You can also have a digital signature extansion for your applications. The cons are: The certificates should be able to sign object, not SSL. You have to spend your resource to impletement this part which is not ready in CAS. Good luck, Shi Yusen/Beijing Langhua Ltd. 在 2008-06-10二的 15:50 -0400，Sean R. McNamara写道： > 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
