On my Windows PC my primary tool for accessing subversion repositories is TortoiseSVN. A while ago I updated to TortoiseSVN 1.8.4. This version of TortoiseSVN is based upon Subversion 1.8. So I migrated all my working copies from SVN 1.7 to 1.8. So far, so good.
Unfortunately later I realized that SvnKit in NetBeans 7.4 is still based on Subversion 1.7 and no update to 1.8 is available by now. So SvnKit started telling me “sorry, SvnKit is too old to work together with your SVN working copy”. No problem, I thought. I switched to command line tools (CLI) as mentioned by SvnKit. All went good, except for repositories via HTTPS using SSL/TLS certificates signed by an internal root-CA and self-signed certificates respectively.
When I tired to access such a repository I got the following response (see figure 1, too):
svn: E230001: Unable to connect to a repository at URL 'https://svn.example.com/project/trunk' svn: E230001: Server SSL certificate verification failed: issuer is not trusted
Unluckily there was no way to accept the untrusted SSL certificate.
Figure 1: NetBeans’ SVN failure message.
A research on the Internet brought up this bug report in NetBeans 7.4:
https://netbeans.org/bugzilla/show_bug.cgi?id=232378
Unfortunately this bug is fixed in the development branch of NetBeans only which will become version 8.0. For the current release 7.4 there is no fix available or planned. So I played a bit with my configuration and was successful. I found a simple workaround!
Trusting the Untrusted
In NetBeans you will find a configuration file
%USERPROFILE%\AppData\Roaming\NetBeans\7.4\config\svn\config\servers
in your user profile. This is the servers configuration file which is known from Subversion’s client tool svn. Simply edit this file and add a group for your untrusted certificate(s).
For example: If your servers belong to the domain example.com and your corresponding root-CA’s certificate is stored in the file C:\certificates\example-ca.crt, add the following lines:
[groups] example1 = *.example.com [example1] ssl-authority-files = c:/certificates/example-ca.crt
If you have a single server with a self-signed certificate only, add lines like the following. The server in this example is svn.example.com and its certificate is stored in C:\certificates\svn.example.com.crt.
[groups] svn1 = svn.example.com [svn1] ssl-authority-files = c:/certificates/svn.example.com.crt
Unfortunately editing this file is not enough. When I tried to access my repository after these changes. The connection worked but operations afterward failed again. I found out that NetBeans simply overwrote my changes in servers with empty settings.
So I typed in my changes again and changed the file permissions of servers by Windows’ file explorer to read-only. This is enough to prevent NetBeans from overwriting the file. After this little trick my problem was solved permanently. I hope it will survive future updates in NetBeans 7.4, too.
Having the exact same problem. But, I do not see this folder. Could these configuration setting be located elsewhere? Can I create this folder/file myself?
Note that
AppDatais a hidden folder in your user’s profile (%USERPROFILE%).The easiest way to open the mentioned folder without modifying any settings in your Windows Explorer is the following:
%USERPROFILE%\AppData\Roaming\NetBeans\7.4\config\svn\configNow you should see the file
servers. This works fine on Windows Vista and Windows 7.On Windows 8 the following steps should work but I could not test it yet:
%USERPROFILE%\AppData\Roaming\NetBeans\7.4\config\svn\configI hope this will fix your problem. Let me know whether it worked.
The issue I had was that the certificate was not trusted. I was able to correct this by using Internet Explorer to browse to the repository URL, viewing the certificate and then importing the certificate. After this, the certificate was trusted.
In my case the certificate was already trusted by Internet Explorer. In the past I had used Internet Exlorer as well as other browsers to browse the repository before I upgraded to TortoiseSVN 1.8.4 and Subversion 1.8 respectively.
Can you describe your setup, please? — Maybe you’ve found a better solution which is easier to apply.