How to set up a secure webdav area on an Apache 2.0 server that can hold an Adobe Acrobat 8 shared review document

Adobe Acrobat 8 has a new powerful feature for distributed authoring called "shared review". In a shared review, the lead author creates a draft of the document using Acrobat 8. He then posts a copy in a read-only area on a web site and sends around an email message to the other others that contains a link to the original. When the recipients of the email open the draft document in Adobe Reader 8 (only the free reader is required to do this!) it opens with instructions on how to edit their changes into the document. It also provides two sharing buttons, one to share one's own changes with fellow authors and the other to update one's copy with changes entered by others. All of this happens live, so that changes shared by one author can be concurrently imported by all other authors at the moment they are shared or any time thereafter.

Adobe talks webdav
The network communication is handled transparently by Adobe Reader using the webdav protocol. Obviously, the original author has to set that up. He does that by entering the url of a webdav area that will hold the updates. This is different from the draft document itself and need not even be on the same web server, although obviously it can be.

Having already learned how to set up a secure webdav area on an Apache 2.0 server that is mountable from windows I though that it would be easy to configure my server to host Acrobat shared reviews. How wrong I was!

Problem 1: Acrobat 8 complains that "The Shared Folder Location provided is not valid"
This problem I managed to solve, at least on the Windows version of Acrobat 8. It was complicated by the fact that the http communication is done by Acrobat behind the scenes without any way for the user to see or manage how the connection is being handled. When the connection uses ssl, how certificates are being validated and how client certificates, if any, are being selected is mysterious. I decided right away to give up on client certificates, and just try to use http basic authentication over ssl to protect my site. Even this was not easy. The reason for this was that my ssl.conf configuration for the secure portion of my web site contained the following couple of lines SSLVerifyClient optional SSLVerifyDepth 10 By luck and a lot of trial and error, I discovered that commenting out these lines allowed the Acrobat 8 ssl key exchange to work with my Apache server. Unfortunately, this conflicts with another application on my web site, phpMyAdmin, which I protect using a private client certificate. Removing the SSLVerifyClient optional setting from the top-level of my site ssl configuration made the client authentication fail for phpMyAdmin, even when the SSLVerifyClient directives from the top level that had made the configuration work were moved into the phpMyAdmin directory clause. Fortunately, my server hosts multiple IP addresses, so it was easy to set up two virtual hosts and dedicate one to serving webdav for Acrobat shared reviews.

Because fellow authors rarely have client certificates that I know I can rely on, it is easier to use http basic authentication anyway, so I never tried to get client certs to work with Acrobat shared reviews. Maybe some day when pki technology becomes widespread in the scientific community, it will make sense to revisit the question.