Ralph Seichter wrote:
>>This of course has the side effect of requiring ALL clients that
>>connect to the server to supply a valid certificate.
>
>
> ...this is a side effect the users won't accept, because the machine
> serves non-SVN clients aswell. For example, the SquirrelMail users
> have no client certificates available in their Web Browsers.
>
Yes, that is a problem.
> Indeed. I don't know if this could be called a misbehaviour of SVN,
> though. The Apache docs state that SSLVerifyClient is valid in the
> contexts server config, virtual host, directory, and .htaccess; see
> <http://httpd.apache.org/docs-2.0/en/mod/mod_ssl.html#sslverifyclient>.
> I tried to use SSLVerifyClient in a <Location> section, which works
> for Firefox and Internet Exploiter, but not for SVN... Should this
> be reported as a SVN bug or not?
It is a bug in SVN and should be reported. Specifically the SVN client
chokes when the server requests a client certificate after the initial
handshake. This might be a problem with the neon library SVN uses to
connect to the server, or in the way SVN is using neon.
> It seems like I'm stuck now. I need a configuration which allows
> access to the server in the following manner:
>
> https://server.tld/subversion/ SVN, client certificates only
> https://server.tld/webmail/ Web Browsers, no certificates
>
> Can this be done (and how)?
>
As a workaround, you can set up a listen directive on an alternate port,
and then use the SSLVerifyClient directive to require client certs for
all connections to that port. Then you just need to have your svn
clients specify that port in the URL when accessing the repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 6 22:12:11 2005