Most Annoying Bug Ever
I've just spent the past three or four hours setting up Apache, Subversion, all my browsers etc etc to use SSL connections and client certificates for authentication with my Debian stable server. I'm sure the mod_ssl devs already know what's coming here and are either chuckling gleefully or ripping their hair out right now. Anyway, the joke for all those who are mod_ssl devs, is that you can't get subversion to use client certificates with a Debian stable server because Debian stable has Apache 2.0.54, complete with everybody's favorite mod_ssl bug. It's fixed in Apache 2.2, but not in 2.0.
So, back to basic authentication over SSL. Sigh, I had that working about two hours ago.
March 28th, 2007 at 9:57 am
FWIW, we’ve been working around this bug for a long time now here at APNIC. You can resolve it by ensuring that the strongest authentication you will need is negotiated at connect time, that is, by putting your SSL directives at the outermost configuration level, or inside a level for an IP based virtual host (not name based — the host name is part of the HTTP request headers). In your case, this would imply that you either (a) run a server on a non-standard port specifically for SVN, or (b) require client certificates for your entire https address.
Of course, you probably already know this, but hey, someone else reading your blog might not. :)
March 28th, 2007 at 10:03 am
hmm, I was going to say that’s what I’m doing already, but I’m actually using name based virtual hosts which is pretty stupid for SSL now that I think about it. Might have to investigate not making *:443 a name virtual host and see where that leads.
March 28th, 2007 at 5:00 pm
Nope, removing the virtual hosts doesn’t help either. From the comments on the bug it sounds like any time the first connection to the server has post content (like say, the stuff the subversion protocol sends) it fails. So, no client certificates for me. Oh well.
March 28th, 2007 at 5:07 pm
Correction, removing the name based virtual hosts, moving the SSLVerifyClient directives outside of any Location elements and disabling the potential for basic authentication seems to make it work. Yay! Now of course I have no fall back to basic authentication when I’m on a browser that doesn’t have my client certificate and no way to access my blog’s admin page since it’s on the name based virtual host that I just disabled and it’s set to require SSL. I guess that’s the next piece of the puzzle to set up.
April 2nd, 2007 at 9:58 pm
I found the best solution to this was to run my client-cert-mandatory SSL virtual host on a non-standard high port, leaving port 443 for tasks that didn’t require a client cert. Clumsy, but effective.
April 10th, 2007 at 8:19 pm
[...] know. I'll probably make an attempt to upgrade to PHP5 and fiddle with the SSL set up now that the most annoying bug in the world is fixed. There's probably a bunch of other stuff I can actually do now that the [...]
August 21st, 2007 at 9:44 am
can you by any chance recommend a tutorial for use with SSL and apache?