# SVN - HTTPS support not working



## multix (Dec 11, 2013)

HI,

I need to access a SVN repository that has an https:// url  (not SSH). When I try to access it, I get: 
	
	



```
svn: E120171: Unable to connect to a repository at URL 'https://xxxxxxxxx/trunk'
svn: E120171: Error running context: An error occurred during SSL communication
```

The URL is right, it works with other systems and I even copied a working repository from another machine and did "update".

I think it is failing to get WebDAV support? *T*he serf library is installed. I have:

```
serf-1.3.2_1        Serf HTTP client library
subversion-1.8.5    Version control system
```

*W*hat could be missing? neon? Does subversion have options in the build?

Thanks.


----------



## ShelLuser (Dec 11, 2013)

That the required library is installed on your system isn't proof that Subversion is actually using it 

Which brings me to the important question here: how did you install Subversion on this machine? And also; which version of FreeBSD are you using?

The most common way to determine if Subversion is up to the challenge is to use this command: `# make -C /usr/ports/devel/subversion showconfig`. That should at least list the following line:


```
SERF=on: WebDAV/Delta-V (HTTP/HTTPS) repo access module
```
However, if you installed Subversion using binary packages then my guess is that it doesn't support this feature. I'm not sure because I don't use binary packages myself, but I do know that they often don't provide the full amount of features.


----------



## multix (Dec 11, 2013)

Hi,

I am running FreeBSD 9.2-RELEASE. Packages are installed by compiling from current ports, updated as today with portsnap. My configuration is as follows:

```
BDB=off: Berkeley DB support
     DOCS=on: Build and/or install documentation
     FREEBSD_TEMPLATE=on: FreeBSD Project log template
     GNOME_KEYRING=off: Build with GNOME Keyring auth support
     KDE_KWALLET=off: Build with KDE KWallet auth support
     MAINTAINER_DEBUG=off: Build debug version
     MOD_DAV_SVN=off: mod_dav_svn module for Apache 2.X
     NLS=on: Native Language Support
     P4_STYLE_MARKERS=on: Perforce-style conflict markers
     SASL=off: SASL support
     SERF=on: WebDAV/Delta-V (HTTP/HTTPS) repo access module
     STATIC=off: Build static version (no shared libs)
     SVNSERVE_WRAPPER=off: Enable svnserve wrapper (umask setter)
     TEST=off: Run subversion test suite
     TOOLS=off: Install several tools (svnauthz-validate and mod_dontdothat are among them)
```

Serf itself has no meaningful configuration. Which tells me the SERF module should be there, thus I wonder even more why it is not working.

Thanks.


----------



## wblock@ (Dec 11, 2013)

multix said:
			
		

> HI,
> 
> I need to access a SVN repository that has an https:// url  (not SSH). When I try to access it, I get:
> 
> ...



That may not be an HTTPS problem.  It could caused by a firewall on the local or remote machine, or some other connection problem.  If the repository supports it, try svn:// to see if the same error occurs.


----------



## multix (Dec 11, 2013)

It is not a firewall problem. It works from the same place, from a computer in the same subnet using HTTPS with other OSs (I got it to work con NetBSD, OpenBSD, Linux and even mingw!).


----------



## wblock@ (Dec 11, 2013)

It could be a firewall on the FreeBSD client itself.  If it the plain svn:// works, it would verify that the problem is with HTTPS.


----------



## multix (Dec 11, 2013)

The repository works HTTPS only, sadly. I use SVN successfully with other repositories which have SSH. Firewall, like what? I don't have installed anything willingly on my laptop. Perhaps it is there and I don't know, does it come from base? I didn't install anything explicitly from ports.


----------



## ShelLuser (Dec 11, 2013)

Then my guess is that something went wrong somewhere in the past with the upgrade of some of your ports. This is an assumption mind you, but some of the Subversion dependencies required specific steps to upgrade:


```
root@smtp2:/usr/ports/devel/subversion # make run-depends-list
/usr/ports/databases/db42
/usr/ports/databases/sqlite3
/usr/ports/devel/apr1
/usr/ports/devel/gettext
/usr/ports/textproc/expat2
/usr/ports/www/serf
root@smtp2:/usr/ports/devel/subversion # make -C ../../www/serf run-depends-list
/usr/ports/devel/apr1
```
And when looking at devel/apr1 in /usr/ports/UPDATING:


```
20130706:                                                                         AFFECTS: users of devel/apr1
  AUTHOR: ohauer@FreeBSD.org

  APR was updated to 1.4.8 and APR-util was updated to 1.5.2.

  Please rebuild all ports which are using functions from APR/APR-util
  such as Apache, Subversion, etc.

  # portmaster -r apr
    or
  # portupgrade -r devel/apr1
    or
  # pkg install -fR devel/apr1
```
Note that I'm not claiming that devel/apr1 is the cause of all this, but it is most certainly a very reasonable assumption. Because this port provides HTTPS support for several other programs (like www/apache22 for example).

As such my question: how well have you been paying attention to /usr/ports/UPDATING as of late?

When all else fails my suggestion, though it is a bit drastic, would be to enforce a rebuild of Subversion and everything it depends on. So basically using a command such as this: `# portmaster -f devel/subversion`.

However, if you haven't been following the instructions which I quoted above then that would be a better approach. Because that will also rule out any issues which other ports might run into.


----------



## ljboiler (Dec 11, 2013)

multix said:
			
		

> The repository works HTTPS only, sadly. I use SVN successfully with other repositories which have SSH. Firewall, like what? I don't have installed anything willingly on my laptop. Perhaps it is there and I don't know... does it come from base? I didn't install anything explicitly from ports.



Does this mean that you have successfully connected to these "other repositories" from this laptop?  If the answer is yes, then I would suspect you might be dealing with an SSL certificate problem.


----------



## multix (Dec 11, 2013)

*W*ell, since I had problems with seamonkey crashing, I removed with `pkg_delete` ALL packages, I removed /usr/local, /var/db/pkg and /var/db/ports and reinstalled everything from scratch, thus the current subversion client is clean (seamonkey is still building, as it apparently pulls in whole gcc 4.6)

SVN wasn't working before, but isn't yet either, but it is a clean build and shouldn't be an upgrade problem.


----------



## multix (Dec 11, 2013)

ljboiler said:
			
		

> Does this mean that you have successfully connected to these "other repositories" from this laptop?  If the answer is yes, then I would suspect you might be dealing with a SSL certificate problem.



The certificate is most certainly self-signed. On other OS's I get asked if I want to permanently accept it and then if I want to save my password.
I


----------



## ShelLuser (Dec 11, 2013)

Then I can think of only one option to determine what is happening here. Install www/lynx and be sure to enable support for SSL. Then use lynx to access the HTTPS URL. If that also fails then the cause of the problem isn't so much Subversion but lies elsewhere.


----------



## wblock@ (Dec 11, 2013)

multix said:
			
		

> The repository works HTTPS only, sadly. I use SVN successfully with other repositories which have SSH. Firewall, like what? I don't have installed anything willingly on my laptop. Perhaps it is there and I don't know, does it come from base? I didn't install anything explicitly from ports.



ipfw(8) and pf are installed by default, and can be enabled with a single setting in /etc/rc.conf.  (It doesn't happen often, but sometimes.)

How about using an HTTPS-capable browser on the FreeBSD client to connect to the repository?  www/lynx can do it if a graphical browser is not available.


----------



## multix (Dec 13, 2013)

Thanks for the support, investigation is continuing.

 I don't have ipfwor pf enabled in /etc/rc.conf, checked.
 I was able to connect to the repository using Seamonkey, this means that 1) is confirmed and the problem is on the svnside.

*B*efore connecting though, Seamonkey asked to add the certificate with a security exception (it is self-signed, I suppose, internal server). Perhaps SVN needs a way to do that too? On other systems I got asked about the certificate and if to accept it permanently, on FreeBSD not. Perhaps there is a configuration to change somewhere, a different default?


----------



## wblock@ (Dec 13, 2013)

If svn does not already know the server's certificate, it will prompt as shown in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn-mirrors.html.  If accepted permanently, that information is stored in ~/.subversion.  Maybe that directory is not readable or writable for the user?


----------



## multix (Dec 13, 2013)

wblock@ said:
			
		

> If `svn` does not already know the server's certificate, it will prompt as shown in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn-mirrors.html.  If accepted permanently, that information is stored in ~/.subversion.  Maybe that directory is not readable or writable for the user?


It is. I touched a file inside and I can do that. Everything is correctly user:group owned. Could it be possible that for some reason SVN is not using or detecting the module I need? Is there a command to print out at runtime? That would also allow me to check against Linux and NetBSD where I have it working.


----------



## ShelLuser (Dec 13, 2013)

multix said:
			
		

> *B*efore connecting though, Seamonkey asked to add the certificate with a security exception (it is self-signed, I suppose, internal server).


Now we're getting somewhere!

This does indeed put the focus completely on Subversion and it's apparent inability to use the HTTP protocol. First of all; there is more to the ~/.subversion directory than merely the entry itself. Start by checking if there are any entries in the ~/.subversion/auth/svn.ssl.server directory (where ~ is of course an alias for your home directory).

Be sure to check the right directory   I'm just mentioning this because I started to check my personal home directory for this message (~peter) while in fact I should have been looking at /root/.subversion instead .

If there are any entries there: remove them and try again.

But at this stage I think your best option to get rid of this problem is to rebuild Subversion and the ports it depends on, as I already mentioned in an earlier message.


----------

