To partially answer my own question, I've discovered a workaround that
at least makes the svn client usable in this situation. Rather than
recap the issue, I've quoted my original email in full at the bottom.
The solution is to create a dummy, passwordless certificate, that is
signed by a CA that the Apache server running mod_dav_svn trusts.
Assuming you don't actually want to log in via certificates, this
certificate should identify a dummy user that has been granted no
permissions via mod_authz_svn. Having created this certificate, you can
tell the svn client to use it for the server via the
ssl-client-cert-file directive in the servers config file. The effect
of all this is that when the svn client sees the optional certificate
request, it automatically and silently tries to authenticate with the
dummy certificate. The server recognises the certificate, but rejects
it as the user identified by the certificate has no permissions within
the repository. The svn client then silently falls back to password
authentication. The end-user sees none of this - they just get prompted
for a password, or don't even get that if they already have an
appropriate password cached.
As the certificate is a dummy certificate whose "user" has been granted
no privileges, this certificate can be given to anyone who needs to use
areas that have been set up to accept both password and certificate
authentication. Once set up in their servers file, it has the effect of
disabling certificate authentication for that server. The dummy
certificate does have to be signed by a CA that the server trusts,
however, otherwise the server completely rejects the certificate and the
svn client displays an error and stops.
I hope this is of use to someone. It's a horrible workaround, but at
least it is a workaround!
Thanks,
Max
Max Spicer wrote:
> I am setting up a repository that is accessible only via https and only
> to authenticated users. Most users log in via basic auth over https,
> but some automated scripts need to log in with client certificates
> instead. I've successfully set up my Apache 2.2 server and
> mod_authz_svn to do what I need, but have run into problems with the way
> the svn client responds to Apache's SSLVerifyClient optional. Whenever
> I perform an svn command (e.g. co, ls, log etc) against an area
> configured in this way, svn asks me to specify the Client certificate
> filename. The majority of users don't have a client certificate, so
> this is a problem - they have to press enter three times before the
> prompt goes away, at which point the command just works, as svn has
> already cached their perfectly acceptable basic auth credentials.
>
> Here's an example session:
>
> host0:~$ svn ls https://repos.example.com/repos
> Authentication realm: https://repos.example.com:443
> Client certificate filename: [user presses enter]
> Authentication realm: https://repos.example.com:443
> Client certificate filename: [user presses enter]
> Authentication realm: https://repos.example.com:443
> Client certificate filename: [user presses enter]
> mainProject/
> otherProject/
> host0:~$
>
> You can see that at the end the svn ls completes successfuly once the
> user has finally got past the unnecessary filename prompts.
>
> What I'd like to know is if there is anyway to suppress the Client
> certificate filename prompts? I've tried various hacks with pointing
> ssl-client-cert-file to empty or garbage files in the servers config
> file but to no avail. I can't point it to an acceptable certificate as
> the client doesn't have one. I have found an open bug on this that
> would solve my problem -
> http://subversion.tigris.org/issues/show_bug.cgi?id=2410. However, this
> is quite old now. This talks about allowing the client to disable
> client certificate requests altogether, which would certainly work.
> Another solution would be to try basic auth login before assuming that a
> client certificate has to be supplied.
>
> For now, I'm just going to have to limit the directories that have
> SSLVerifyClient Optional specified against them in order to minimise the
> user disruption. I'd really appreciate any other tips that anyone could
> offer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 31 13:31:23 2007