x509 login broken in Safari

[Shi Yusen]

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
> >> cas at tp.its.yale.edu
> >> http://tp.its.yale.edu/mailman/listinfo/cas
> >>     
> >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >   
>