SVN (TortoiseSVN / SlikSVN) - Server certificate changed: connection intercepted?

I was getting this error when trying to commit changes to my repository. I could commit changes a few files at a time, but if I tried too many, the commit would fail. I thought maybe if I renewed the SSL certificate, perhaps that would help (it was going to expire in a few weeks anyway, but was currently valid). After doing this and restarting Apache, same thing. I also tried to restart the server:开发者_Go百科 same thing. Then I tried to delete all of the cached certificates and credentials from Tortoise SVN and try again. This time, I can do nothing - even "svn info" reports:

svn: OPTIONS of __URL__: Server certificate changed: connection interceptd? (__BASE_REPO_URL__)

This from slik SVN command line, after providing the correct credentials.

The only useful solution I found online (untested by me) was to checkout a new working copy, but this means I would have to merge my changes in to the fresh working copy by hand, and that's not very exciting.

Any ideas?

Thanks!

EDIT: I am also unable to check out a new working copy. Same error as above.

The issue is that the SVN client is caching the old server identity and doing a direct comparison of the whole certificate to see whether there's been a change. You've changed it by renewing (fair enough) but now you need to purge that local cache so that you don't compare with the old version. (Apparently, the configuration is somewhere in %USERPROFILE%\AppData\Roaming\Subversion\config but I can't personally verify this or say exactly what you're looking for in there.)

Solved. Some time back I was having trouble with commits/checkouts when a large number of files were involved. I cannot remember all of the details (I think it had something to do with per-directory repository access), but I remember that modifying my Apache SSL configuration and turning off TLSv1 solved the issue. Evidently, that fix caused this new error which only showed up after several months and hundreds of commits, hmmm...:

Caused this problem: SSLProtocol -aLL +SSLv2 +SSLv3 (no TLS!)
Fixed this problem: SSLProtocol aLL

Note: SSLProtocol aLL is the default ;)

I don't know if this will cause the original problem to return or not, as that old access restriction is no longer necessary and has been removed.