subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Widdis <wid...@gmail.com>
Subject Re: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate
Date Tue, 04 Mar 2014 01:03:10 GMT
Here's the two SVN versions from macports (1.8.5 doesn't give error, 
1.8.8 does).

<danielwiddis> ~ $ svn --version -v
svn, version 1.8.5 (r1542147)
    compiled Feb 28 2014, 19:40:14 on x86_64-apple-darwin13.0.0

<danielwiddis> ~ $ svn --version -v
svn, version 1.8.8 (r1568071)
    compiled Feb 28 2014, 11:51:30 on x86_64-apple-darwin13.0.0

Both have identical information in the ra_serf section.

* ra_serf : Module for accessing a repository via WebDAV protocol using 
serf.
   - using serf 1.3.2
   - handles 'http' scheme
   - handles 'https' scheme

Lots of other output if you think any of it is relevant.  As I mentioned 
in another email, macports doesn't have serf 1.3.4 but I can pursue 
downloading and installing it separately if I can muddle through it.

Happy to forward key cert or other info, although I may need some 
pointers on where to find what you want on a Windows 2008 
server/SmartSVN setup.

On 3/3/14, 5:23 PM, Ben Reser wrote:
> On 3/3/14, 2:50 AM, Bert Huijben wrote:
>>> -----Original Message-----
>>> From: Daniel Widdis [mailto:widdis@gmail.com]
>>> Sent: zaterdag 1 maart 2014 05:06
>>> To: users@subversion.apache.org
>>> Subject: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP
>>> certificate
>>>
>>> I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version
>>> refused to permanently accept my self-signed certificate, citing an
>>> "unknown error".
> Some background on this issue here:
> http://stackoverflow.com/questions/22108914/subversion-server-ssl-certificate-verification-failed-and-other-reasons
>
>> We fixed a bug in Subversion where we accidentally accepted certificate
>> issues that were reported after a different first certificate problem.
>>
>> My guess would be that your selfsigned certificate is not completely valid,
>> but we accidentally accepted it before because the first report was just
>> that you weren't a known certificate authority. The second error could then
>> be something like a problem in the certificate chain.
> Bert's talking about this change from the CHANGES file:
>      * ra_serf: properly ask multiple certificate validation providers for
>        acceptance of certificate failures (r1535532)
>
> Which is this change:
> http://svn.apache.org/r1535532
>
> I was under the impression that this didn't impact our command line client
> because of the commit message that says we accept all or none of the failures.
>   Looking at the code reinforces that view.
>
> It's possible this change is somehow involved, but I'm not seeing how.
>
>> It could help to upgrade your serf to the latest version as this changes the
>> handling of a few certificate checks.
>>
>> If the internal error is X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE (which I
>> happened to reproduce locally some time ago), upgrading to the latest serf
>> should resolve this problem for you.
> The X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE error issue doesn't make any
> sense in the context of a self-signed certificate so I really don't think this
> related.
>
> Can you verify which version of serf you're using.  You can find this out by
> running: svn --version -v
>
> You'll get a lot of output but you're looking for this:
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>    - using serf 1.3.4
>    - handles 'http' scheme
>    - handles 'https' scheme
>
> If you can do this with both the 1.8.5 and 1.8.8 version that would be
> interesting.  I don't use MacPorts myself but it looks like the serf-1 package
> can be independently upgraded from subversion.
>
> We were discussing this on IRC and Lieven suggested that we ask that you
> generate a new key/cert pair and send them to us so we can try and replicate
> the behavior.  Because as things stand we're not sure what's wrong with the
> certificate to trigger that other error.  Your httpd.conf details would
> probably be helpful as well.


Mime
View raw message