Re: [Simpleweb-Support] SSL client certificate request: Safari 5 problem?

[<nia...@rb...>]

Hi,

I am removing this from the Handshake as it is not required, in future implementations wanting client authentication will have to intercept the SSLEngine in the transport layer to set the value. This allows for customization without forcing the client to ask for the certificate. This should be released this week some time.

Niall  

-----Original Message-----
From: Bruno Harbulot [mailto:Bru...@ma...] 
Sent: 09 July 2010 10:05
To: Andrew Barlow
Cc: GALLAGHER, Niall, GBM
Subject: Re: [Simpleweb-Support] SSL client certificate request: Safari 5 problem?

Hi,

setWantClientAuth(true) is hard-coded in org.simpleframework.transport.Handshake (run() method): 
http://www.simpleframework.org/doc/source/org.simpleframework.transport.Handshake.html

There would need to be a way to pass a parameter there, I'm not sure how.

Best wishes,

Bruno.


On 09/07/2010 09:52, Andrew Barlow wrote:
> Thanks Bruno
>
> I don't need to authenticate the client certificate.
>
> Do you know of any way to switch this off in Simple?
>
> AndyB
>
> On 8 Jul 2010, at 23:57, Bruno Harbulot wrote:
>
>> Hi,
>>
>> SimpleWeb always requests (but doesn't require) a client certificate 
>> during the SSL handshake.
>>
>> Safari's client-certificate mechanism was broken (it wouldn't prompt 
>> when it should have) so that's probably why the message didn't appear 
>> in version 4. I guess this has been fixed in Safari 5 (but I haven't 
>> tried).
>>
>> For the certificate to be accepted, it would need to be verifiable by 
>> the server, so its emitter (or something higher up in the chain) 
>> should be in the server's trust store.
>>
>> If you're not really using client-certificate authentication and 
>> seeing this only as a side-effect of SimpleWeb requesting a client 
>> certificate by default (I think it's hard-coded in fact), I'd suggest 
>> clicking on Cancel rather than choosing a certificate. This shouldn't 
>> send a client-cert and thus the server wouldn't have to verify it.
>>
>>
>> Best wishes,
>>
>> Bruno.
>>
>>
>>
>> On 08/07/2010 10:14, Andrew Barlow wrote:
>>> Niall and Fabio kindly sent me links to example code for delivering 
>>> web content over SSL, see 
>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilp2L
>>> qrCGMJ5Io6hxFOJMLZqIYGNutDmYslm-gP%40mail.gmail.com&forum_name=simpl
>>> eweb-support 
>>> <http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilp2
>>> LqrCGMJ5Io6hxFOJMLZqIYGNutDmYslm-gP%40mail.gmail.com&forum_name=simp
>>> leweb-support> 
>>> <http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilp2
>>> LqrCGMJ5Io6hxFOJMLZqIYGNutDmYslm-gP%40mail.gmail.com&forum_name=simp
>>> leweb-support 
>>> <http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTilp2LqrCGMJ5Io6hxFOJMLZqIYGNutDmYslm-gP%40mail.gmail.com&forum_name=simpleweb-support>>.
>>>
>>> As I need to use an existing signed certificate inside a Java 
>>> keystore I've adopted/adapted Fabio's example which reads from the keystore file.
>>>
>>> I have set the SSLContext to "TLS".
>>>
>>> I've tested against a keystore containing a bona-fide signed 
>>> certificate issued by Thawte and all is well across a range of 
>>> browsers: Internet Explorer on Windows and Firefox, Opera, Chrome on Windows and Mac.
>>>
>>> However on Safari 5 (but NOT 4) on the Mac I encounter a message 
>>> asking for a client certificate, see screenshot:
>>>
>>>
>>> Upon selecting a certificate (doesn't matter which), Safari then 
>>> gives a
>>> message:
>>>
>>> "Safari can't open the page "xxxx" because Safari can't establish a 
>>> secure connection to the server "xxxx".
>>>
>>> On Windows behaviour is slightly different, Safari 5 simply displays 
>>> the message without prompting for client certificate.
>>>
>>> As this works fine with other browsers, including earlier version of 
>>> Safari could this be an Safari 5 issue that needs to be addressed by 
>>> Apple?
>>>
>>> Andy Barlow - Chief Technology Officer - MBCS CENG EURING CITP
>>>
>>> e: and...@sd... 
>>> <mailto:and...@sd...>
>>> <mailto:and...@sd...>
>>> t: +44 (0)7830 302 268
>
> Andy Barlow - Chief Technology Officer - MBCS CENG EURING CITP
>
> e: and...@sd... <mailto:and...@sd...>
> t: +44 (0)7830 302 268
>
> /The information in this email or facsimile is confidential and is 
> intended solely for the addressee(s) and access to this email or 
> facsimile by anyone else is unauthorised. If you are not the intended 
> recipient then any disclosure, copying, distribution or any action 
> taken or omitted to be taken in reliance on it, is prohibited and may 
> be unlawful. Information expressed in this email or facsimile is not 
> given or endorsed by my firm or employer unless otherwise indicated by 
> an authorised representative independent of this message./
>

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 10, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions.
 
This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. 

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will 
not adversely affect its systems or data. No responsibility is accepted 
by the RBS group in this regard and the recipient should carry out such 
virus and other checks as it considers appropriate. 

Visit our website at www.rbs.com

***********************************************************************************