I find that the SSLOptions +FakeBasicAuth combined with AuthType Basic
is a kludge. Rather than fake the basic authentication information
using the full DN in the certificate and the password 'password' then
having basic auth see and verify that against the auth file, I find that
it is better to use SSLUserName to have the mod_ssl directly fill out
the logged in user name with the CN from the certificate, and not use
AuthType Basic and AuthUserFile at all.
Also, are you saying that when using SSLVerifyClient optional in the
root of the vhost, then setting it to required for the location /svn,
svn does not choke when asked for the client cert, but a normal web
browser is able to access the root over SSL without a client certificate?
I have not been able to do that I believe, because svn has a bug in
handling a request for a client cert after the initial handshake, which
I believe that config will cause since the server does not know to ask
the client for a cert until after it requests access to /svn.
Ralph Seichter wrote:
>I'm still juggling SSL client certificates, SVN and Apache around.
>Currently, I use the following in my Apache configuration:
>
> <VirtualHost _default_:443>
> [...]
>
> SSLVerifyDepth 1
> SSLVerifyClient optional
> SSLOptions +FakeBasicAuth
> <Location /svn>
> SSLVerifyClient require
> SSLRequire %{SSL_CLIENT_I_DN_O} eq "Foobar Inc."
> SSLOptions +StrictRequire
>
> DAV svn
> SVNParentPath /var/svn/repositories
> AuthzSVNAccessFile /var/svn/svn-access
>
> AuthType Basic
> AuthName "Foobar Inc. repository tree"
> AuthUserFile /var/svn/apache-users
> Require valid-user
> Satisfy any
> </Location>
> </VirtualHost>
>
>First the good news: With "SSLVerifyClient optional" in the virtual
>host section and "SSLVerifyClient require" in the location section,
>SVN no longer chokes when prompted for a SSL certificate, while web
>browser based clients can access other parts of the server without
>certificates. A big thank you goes to Joe Orton of the Neon ML for
>telling me to try this workaround!
>
>The trouble is that selectively granting read/write access to the
>repository is giving me gyp. /var/svn/apache-users includes the
>following lines:
>
> /CN=Johnny Walker/emailAddress=john@domain.tld:(pw-hash)
> /CN=jim.beam/emailAddress=jim@otherdomain.tld:(pw-hash)
>
>As usual with "SSLOptions +FakeBasicAuth", the hashed password is
>"password". The file /var/svn/svn-access looks like this (without
>any line breaks in the "admin" line):
>
> [groups]
> admin = mary, /CN=jim.beam/emailAddress=jim@otherdomain.tld,
> /CN=Johnny Walker/emailAddress=john@domain.tld
> [foobar:/]
> @admin = rw
>
>When I try "svn co https://server.tld/svn/foobar/" as either Jim
>Beam or Johnny Walker, the client reports:
>
> svn: REPORT request failed on '/svn/foobar/!svn/vcc/default'
> svn: Not authorized to open root of edit operation.
>
>The server side error messages are:
>
> A failure occurred while driving the update report editor
> [500, #220000]
> Not authorized to open root of edit operation. [500, #220000]
>
>When I replace "@admin = rw" with "* = rw", everything works fine,
>but obviously I don't want to grant write permissions to every
>person accessing the foobar repository. Any ideas? Am I using the
>correct syntax in /var/svn/svn-access? I tried wrapping the user
>names in '' and "" pairs, but this did not seem to have any effect.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 13 19:49:04 2005