Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 02, 2009 — Enterprise Agile Planning expert

Using client certificate with Apache and Subversion

Enterprise Agile Planning

This is not a typical use case for anyone who uses the client certificate with Apache and Subversion.  In general, the client certificate is used for all Apache requests including the SVN related ones. This use case is bit different, and uses client certificates for all Apache requests, but not for Subversion requests. This sounds like a straightforward configuration in Apache configuration file, but it is not.

Usual workaround

The SSLVerifyClient optional directive is used to enforce client certificate based authentication. If it is specified at the <Location /> directive, all non-Subversion requests goes through client certificate based authentication. The SSLVerifyClient none directive is used to avoid using client certificate based authentication. If it is specified at the <Location /svn> directive, the Subversion requests do not  go through this authentication.

413 — Request Entity Too Large

If we use the above workaround, we face 413 Request Entity Too Large while uploading large files using POST method. This is due to bug 12355. According to this bug report, if SSLVerifyClient optional directive is specified at <Location /> directive, the user will face this issue. The bug report claims that it is fixed in Apache 2.0.55, but I faced this issue even in Apache 2.2.11.
The work around is to specify SSLVerifyClient optional at the virtual host level. But then, this setting can be overridden only using <Directory> directive. In our case, it can not be overridden using <Location /svn> directive. Thus the client certificate based authentication is enforced even for SVN requests.

SSLRenegBufferSize directive in Apache 2.2.12

The issue 413 Request Entity Too Large error is occurred when the SSL Renegotiation is attempted, because we specified SSLVerifyClient optional at <Location /> directive. The default size is 2048 bytes, which is not sufficient. In Apache 2.2.12, SSLRenegBufferSize directive is introduced precisely to configure the buffer size. I have not tried this in Apache 2.2.12 yet.

Snippet from Apache 2.2.12 changelog file.

*) mod_ssl: Add SSLRenegBufferSize directive to allow changing the
size of the buffer used for the request-body where necessary
during a per-dir renegotiation. PR 39243. [Joe Orton]

The Hack to overcome this issue

We can not use SSLVerifyClient optional at virtual host level. We also can not let SVN requests go through client certificate based authentication.

We skipped the client based authentication for specific servlets which supports file upload, as far as Apache is concerned. We modified the code to still authenticate using client certificate only for these servlets. By using the following directive we fixed this issue. We also avoid specifying the SSLVerifyClient optional directive at <Location /> directive.

<LocationMatch “^/servlets/(?!(fileUpload1|fileUpload2))”>
SSLVerifyClient optional
SSLVerifyDepth 2
This is not a perfect solution, but it solves the problem on hand. We should upgrade to Apache 2.2.12 and verify if SSLRenegBufferSize directive fixes the problem cleanly.

More from the Blog

View more
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Feb 08, 2021

How does agile apply to an entire organization?

Enterprise Agile Planning
Before we dive into the main subject of this blog post, it is importan ...
Read More
Feb 03, 2021

It took a pandemic to realize why digital transformation actually matters

Enterprise Agile Planning
Before anyone had ever heard of COVID-19, businesses across the globe ...
Read More
Contact Us