You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by NabblesMeThis <ni...@gmail.com> on 2011/08/12 14:32:56 UTC

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

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 <be...@qqmail.nl> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Gero [mailto:gero@ieee.org]
>>> Sent: maandag 6 september 2010 11:37
>>> To: users@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 <ge...@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.