x509 login broken in Safari

[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
>