OK, let's try it your way. I'll set the ground rules:
1x server, NO vhosts, just one main server. Vhosts don't add anything
to this problem and just seem to cloud the issue...
2x locations pointing to separate repos: /repo1 and /repo2
/repo1 requires an SSL client certificate.
/repo2 does not, open house for everyone (or only through other
authentication means).
An objection was raised to my 'documentation' regarding TortoiseSVN
and SSLVerifyClient. Instead of going in depth, I'll refer you to a
mailing list post that has surfaced in many places, including there:
http://tortoisesvn.net/client_certificates
And in fact, the previous reply gives this link:
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/help-onepage.html#tsvn-serversetup-apache-sslcerts
which is the same thing! I'd say it's pretty well documented!
Now, back to the problem: Can't have the 'SSLVerifyClient' directive
in a <Directory> block, as specified in Nigel Green's post (ie, the
doc!). It doesn't talk about <Location> blocks, but I've tried,
doesn't work either.
In the main server, can't have 'SSLVerifyClient require' or 'none',
this violates access rules to one of the repos. That leaves
'SSLVerifyClient optional' with, in the <Location /repo1> block, the
directive:
SSLRequire %{SSL_CLIENT_VERIFY} eq "SUCCESS"
again, from Green's post... (and I can't imagine what this guy went
through to figure all that...)
Now, none of this is fantasy: it works fine with a web browser. Only
TortoiseSVN complains there is no certificate when accessing /
repo2....
Would anyone like to show me the proper way to do it with TSVN?
(without the dialog constantly popping up?)
If you think of it, it's no surprise that all browser/mail
applications dealing with client certificates have a dialog (or a
config file) where users can manage these things (add, delete, etc.).
It's specifically so that when a certificate is requested, the
application knows that if the user didn't give one previously, then
there is none to supply, and it can just tell the server so...
Now for the 'SSL limitations' comment: The link given is an
interesting one. Outlines a lot of what I've seen on the subject. But
sadly, it is very much incomplete, and completely misses the point
with regards to the current problem. The point of the article/link is:
contrary to popular belief, name-based vhosting is possible, but for a
price. My setup uses the <VirtualHost *:443> scheme shown there, also
much like what is found in Nigel Green's post (again?).
However, here's where the article falls short: once you've figured the
voodoo of OpenSSL (cool voodoo, but voodoo nonetheless), and
discovered the magic of subjectAltName, the price to pay is small
indeed (in my case, none). The article doesn't apply anymore. But that
has nothing to do with server configuration, and everything to do with
certificate management. So again, it misses the point.
Bottom line, both of you guys got on a witch hunt with the vhosts. If
you take them out, the problem doesn't change. TSVN is complaining
when it shouldn't.
Chris
(...and as a side note, I find Stefan's snappy comebacks to be way,
WAY out of line. His reply: "if all repos on vhost1 don't require a
client certificate, then don't make apache ask for one!" Go back and
read Green's post, the links are above. You'll see you simply cannot
do that! User groups are no place for personal attacks, but I think
I'm entitled to this one: I believe I've done my homework... please,
do yours...)
On Jul 28, 10:05 pm, "Craig McQueen" <Craig_McQu..._at_aapl.com.au>
wrote:
> > -----Original Message-----
> > From: Stefan Küng [mailto:tortoise..._at_gmail.com]
> > Sent: Monday, 28 July 2008 4:09 PM
> > To: us..._at_tortoisesvn.tigris.org
> > Subject: Re: clientcertificaterequest cancel: only once
>
> > cri10000 wrote:
>
> > > Stefan: that's a seriously flawed assumption...
>
> > > I'm having the same problem. Here's the setup:
> > > 1x Apache server
> > > 2x vhosts
> > > 7x repos (4 on vhost1, 3 on vhost2)
>
> > > It seems to be well documented that, in order for client
> > certificates
> > > to play nice with TortoiseSVN, Apache must use an 'SSLVerifyClient
> > > optional' directive in the main server section (ie, outside of any
> > > vhosts sections).
>
> > Where is that documented?
>
> http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/help-onepage.html#...
>
> > > This works, but here's the catch: by design, all repos on vhost1
> > > should be accessed WITHOUT a clientcertificate. All repos on vhost2
> > > require it... Better yet, the wish list is: SOME repos on vhost1 as
> > > well as vhost2 require acertificate, the others are in the clear.
> > > Through a browser, I can get this to work fine. But through
> > > TortoiseSVN, it doesn't because of the user is constantly bugged by
> > > this dialog asking for acertificate. (well... in reality
> > it works by
> > > pressing 'cancel' every time the dialog comes up, but no
> > one in their
> > > right mind would consider this a 'usable' or friendly system)
>
> > if all repos on vhost1 don't require a clientcertificate, then don't
> > make apache ask for one!
>
> There are limitations on using SSL with virtual hosts. See for starters:http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html
>
> It sounds as though the original poster is hitting against the limitations of what can be reasonably accomplished with SSL.
>
>
>
> > > The flaw in you reasoning is: don't pass the file, don't
> > get access...
> > > wrong! It must go: don't pass the file, don't get access >>>to those
> > > ressources that require it!<<< Doesn't mean the others are off limit
> > > by implication. TortoiseSVN seems to think so...
>
> > > Here's the problem: from a server point of view (let's take Apache):
> > > 'SSLVerifyClient require' means 'give me a file!', whereas
> > > 'SSLVerifyClient optional' means 'got a file?'
>
> > And 'SSLVerifyClient no' means 'I don't need a file'.
>
> > > Now, from Tortoise's point of view, when told, 'gimme a file', it
> > > shows the dialog asking the user for one, which is the correct
> > > behaviour. But when asked 'got a file?', it keeps on thinking it's
> > > mandatory again, and scrambles back to the user for one. That's a
> > > significant problem. It should just say 'no'...
>
> > There's no way for a client to know why the server asks for a
> > file. If
> > the server asks for it, the client has to ask the user for
> > it. It's as
> > simple as that. If the server later decides that it doesn't
> > really need
> > the file, the client doesn't know that.
>
> > > To quote the first post in this thread: 'it would be nice if
> > > tortoisesvn could remember that it has nocertificate.' I think it
> > > really should remember.
>
> > If you really want such a feature, you'd have to ask on the
> > Subversion
> > mailing list for it: authentication is done by the Subversion
> > library,
> > not TSVN.
>
> > Stefan
>
> > --
> > ___
> > oo // \\ "De Chelonian Mobile"
> > (_,\/ \_/ \ TortoiseSVN
> > \ \_/_\_/> The coolest Interface to (Sub)Version Control
> > /_/ \_\ http://tortoisesvn.net
>
> - The contents of this email, and any attachments, are strictly private and confidential.
> - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed.
> - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd.
> - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers.
> - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use.
> - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
> - Please think before printing this email. Environmental Balance is Everyone's Job.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr..._at_tortoisesvn.tigris.org
> For additional commands, e-mail: users-h..._at_tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-30 07:40:03 CEST