[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SSL handshake failed: SSL error: A TLS warning alert has been received.

From: NabblesMeThis <niall.moran_at_gmail.com>
Date: Fri, 12 Aug 2011 05:32:56 -0700 (PDT)

The same problem has just manifested when using ubuntu lucid either due to a
package update or possibly changes on the server side. I now get the
following error when attempting an svn update (svn info works fine).
 
SSL handshake failed: SSL error: A TLS warning alert has been received.

I tried using the LD_PRELOAD=/usr/lib/libneon.so.27 before the command but
this resulted in the error message:

SSL handshake failed: SSL error code -1/1/336032856

The difference between these being that the first is using a version of
libneon build against gnutls whereas the second uses openssl.

It seems the error in the first case is down to a problem with libneon which
according to the changelog has been fixed in version 0.29-5 (0.29-1 is the
current version for lucid). By building my own libneon (using
-with-ssl=gnutls to specift gnutls rather than openssl) and subversion has
worked. Guess libneon package should be updated to version >= 0.29-5.

Nico Kadel-Garcia-2 wrote:
>
> On Mon, Sep 6, 2010 at 5:40 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Gero [mailto:gero_at_ieee.org]
>>> Sent: maandag 6 september 2010 11:37
>>> To: users_at_subversion.apache.org
>>> Subject: Re: SSL handshake failed: SSL error: A TLS warning alert has
>>> been
>>> received.
>>>
>>> On Wed, 2010-08-18 at 02:06 -0400, Nico Kadel-Garcia wrote:
>>> On Wed, Aug 11, 2010 at 10:24 AM, Gero <gero_at_ieee.org> wrote:
>>>  > > Hi,
>>>  > >
>>>  > > After moving to a new system (Kubuntu Hardy -> Lucid) I can no
>>> longer access
>>>  > > an SVN repository:
>>>  > >
>>>  > > $ svn update
>>>  > > svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL
>>> handshake
>>>  > > failed: SSL error: A TLS warning alert has been received.
>>>  > > (https://example.com)
>>>  >
>>>  > But 'svn info 'https://example.com/path/to/svn/trunk works? What
>>> about
>>>  > doing a clean checkout to a new location?
>>>
>>> 'svn info' with no arguments works and shows info about the repository
>>> in question. 'svn info <repo>', however, does not work, with the same
>>> error message as above. A clean checkout doesn't work either.
>>>
>>> There is an Ubuntu bug report about Subversion not playing with the
>>> latest libneon nor libneon-gnutls. Apparently, libneon now reports more
>>> SSL problems that Subversion should ignore, but doesn't.
>>
>> Subversion uses neon and neon uses your SSL library. Subversion doesn't
>> use
>> the ssl library directly.
>>
>> So this should be fixed either in Neon or (to restore compatibility with
>> the
>> older version) in the SSL library.
>>
>>        Bert
>
> Really? Why do you think this?
>
> For RHEL 5, the RPMforge packages actually have to include
> compatibility versions of python, neon, and swig. Component drift for
> the 4 major and several variant methods of accessing a Subversion
> repository is a demonstrable issue: between local file access,
> svnserve, HTTP, and the minor variants of HTTPS and ssh+svn, you have
> a potential for a lot of subtle version skew in components themselves
> and especially in the interfaces to those components.
>
> It's already awkward with enterprise operating systems, which are very
> reluctant to upgrade system components. (See the RHEL 5 comment, and I
> went through this with SCO OpenServer 5 myself.) It seems
> unsurprising that Ubuntu, that tends to be leading edge, is
> encountering version skew issues from the other side.
>
>

-- 
View this message in context: http://old.nabble.com/SSL-handshake-failed%3A-SSL-error%3A-A-TLS-warning-alert-has-been-received.-tp29409554p32249793.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Received on 2011-08-12 14:33:33 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.