HOWTO setup a client auth ssl connection without verification

[Story Henry <he...@bblfish.net>]

Hi,

I was looking for how I could set up a SSL connection in Tomcat 6.x in  
order to force clients to present a client Certificate. But I don't  
want the server to do any verification of the certificates given to  
it. As long the server can make sure that the client knows the private  
key of the certificate I am happy.

I then want to program a servlet (or whatever the right abstraction  
level should be) to work with the X501 client key information and an  
extra header, to decide whether it can or not trust the client. The  
client os not a normal web browser btw, but a semantic address book  
written in Java.

Bruno Harbulot suggested I use the optional_no_ca option of Apache HTTPD
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
but I was hoping to be able to get the same effect without needing to  
use apache (as that makes setup just one step more complex).

To give you a bit of background on what I am attempting to do you can  
read up on the post I wrote recently
http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword

That post led Toby Inkster to suggest the following even simpler  
protocol:

Re: HOWTO setup a client auth ssl connection without verification

[Bill Barker <wb...@wilshire.com>]

If you are using the APR Connector, then you just need to set 
SSLVerifyClient="optionalNoCA".  To use one of the Java Connectors, then you 
would need to hook in your own TrustStore as per the JSSE documentation. 
Tomcat doesn't provide support this on it's own.

"Story Henry" <he...@bblfish.net> wrote in message 
news:8F1D5809-720B-4B8D-9DB9-9685096B4C22@bblfish.net...
> Hi,
>
> I was looking for how I could set up a SSL connection in Tomcat 6.x in
> order to force clients to present a client Certificate. But I don't
> want the server to do any verification of the certificates given to
> it. As long the server can make sure that the client knows the private
> key of the certificate I am happy.
>
> I then want to program a servlet (or whatever the right abstraction
> level should be) to work with the X501 client key information and an
> extra header, to decide whether it can or not trust the client. The
> client os not a normal web browser btw, but a semantic address book
> written in Java.
>
> Bruno Harbulot suggested I use the optional_no_ca option of Apache HTTPD
> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html
> but I was hoping to be able to get the same effect without needing to
> use apache (as that makes setup just one step more complex).
>
> To give you a bit of background on what I am attempting to do you can
> read up on the post I wrote recently
> http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword
>
> That post led Toby Inkster to suggest the following even simpler
> protocol:
>
>
>


--------------------------------------------------------------------------------


>
>
>
> The 5 steps explained:
>
> 1. Romeo's User Agent GETs Juliette's public foaf file at 
> <http://juliette.org/
> >, that file contains the relation:
>
>  <> rdfs:seeAlso <https://juliette.org/protected/juliette> .
>
> 2. Romeo's UserAgent does a GET on the HTTPS URL
>  and adds to his request the extra identification header:
>
>  Agent-Id: http://romeo.net/#romeo
>
>  All the https handshake stuff goes on as usual. From this Juliette's
> server extracts the hex id of the SSL key used by Romeo's User Agent.
>
>
> 3. Juliette's Server notices the extra header
>  and GETs the resource at http://romeo.net/
>
>  this contains the statements
>
>  :romeo is wot:identity
>            of [ a wot:X509Key;
>                 wot:hex_id "ABC123AB";
>                 wot:pubkeyAddress <http://key.com/romeos.key>;
>               ] .
>
>
> 4. Juliette's Server queries the triples returned in the the
> representations
>  with the SPARQL query
>
>  PREFIX wot: <http://xmlns.com/wot/0.1/>
>  SELECT ?hexid
>  WHERE {
>            [] wot:identity <http://romeo.net/#romeo>;
>               wot:hex_id ?hexid .
>  }
>
> 5. Since Juliette's user agent trusts the URL "http://romeo.name/
> #romeo" - for whatever reason, perhaps her best friend had it in her
> foaf file - and the SSL session was signed by the client with the
> public key identified by hex_id "ABC123AB", she knows that the
> UserAgent has a strong enough trust relation with the person
> identified by <http://romeo.name/#romeo>, and so she returns the
> protected information over SSL.
>
>
>
>
> Home page: http://bblfish.net/
>
> 




---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org