8

I had a SVN system up and working just fine, and after a recent upgrade suddenly stopped working. My setup:

  • I have a repository hosted on a Windows 2008 server using VisualSVN Server 2.7.4. The server offers me the ability to generate self-signed certificates at will, entering my own hostname or other data as desired.

  • I am using Eclipse (Kepler) for java coding on both the hosted machine and my own MacBookPro running Mac OS X 10.9.1 (Mavericks). I have the subclipse add-on to Eclipse which requires subversion with java HL.

  • I have installed macports and the latest subversion/javahl packages requested by subclipse. The Eclipse/subversion interface seems to be working fine, but there are command-line subversion errors which Eclipse isn't navigating well. Solving the command-line errors is the main issue.

  • I previously had the following versions installed via macports, and things seemed to be working fine:

    subversion @1.8.5_1+universal
    subversion-javahlbindings @1.8.5_0+no_bdb+universal

  • As part of installing/troubleshooting something unrelated, I upgraded all my macports, which installed the following new versions:

    subversion @1.8.8_0+universal
    subversion-javahlbindings @1.8.8_0+no_bdb+universal

  • After the upgrade, svn via eclipse on my mac fails. I can force it via the commandline by temporarily accepting a certificate. It still works completely fine on the Windows 2008 server machine.

The first time following a certificate change I get the option to accept permanently, but after doing this, it fails and falls back to a second "temporary" dialogue. 

$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
(credentials dialogue)
At revision 46.
  • Following this, future attempts still result in the error and requirement to temporarily accept:
$ svn update
Updating '.':
Error validating server certificate for 'https://192.168.100.59:443':
 - The certificate hostname does not match.
 - The certificate has an unknown error.
Certificate information:
 - Hostname: 571458-tools1
 - Valid: from Feb 28 23:57:35 2014 GMT until Feb 26 23:57:35 2024 GMT
 - Issuer: 
 - Fingerprint: 55:3E:55:FD:4D:40:A4:1E:8A:1E:27:71:DD:D4:ED:8B:A3:9A:1D:EC
(R)eject or accept (t)emporarily? t
At revision 46.

Multiple web searches, including this site and others, have pointed to the authentication files in ~/.subversion as potentially the problem, but all the proposed solutions (deleting, changing ownership and permissions, etc.) have failed to solve the problem.

Specific questions: 1. I can't figure out how to revert to the previous subversion (1.8.5) in macports to see if there was a bug in the 1.8.8 version I updated to. 2. Assuming there's no bug in 1.8.8, is there anything else I can do to potentially troubleshoot this and get my certificates permanently accepted?

EDIT: - I've been able to get rid of the "hostname" error by changing my self-signed certificate hostname to the numeric IP. However, all other symptoms remain, including the mysterious "The certificate has an unknown error." - I'm convinced (though comments indicate otherwise) that the 1.8.8 upgrade broke something on Mac OS X and am very interested in rolling back versions to troubleshoot further. But I suppose that's a new question...

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63
  • I was able to figure out how to revert to subversion 1.8.5 via this link: https://trac.macports.org/wiki/howto/InstallingOlderPort and reverting to 1.8.5 resolved the problem. – Daniel Widdis Mar 01 '14 at 03:55
  • 1
    And as one last follow-up, apparently there was a bug using subversion 1.8.8 and serf 1.3.2 and earlier. Upgrading serf to 1.3.4 resolved the problem so I am now on the latest version of both subversion and serf. – Daniel Widdis Mar 04 '14 at 16:38

3 Answers3

8

How strange, literally had a similar issue a day ago. Anyway, I may be wrong but the apparent security level for SVN at 1.8.8 is tighter than previous versions. What certificates that you forced svn to accept may no longer be "acceptable" by the new standards. I was wrong, but that's irrelevant.

If you look at the error you provided you will see:

The certificate hostname does not match.

This is a SSL error that svn will not ignore, it implies that you are connecting to a different hostname than what you specified. The thing is, whilst https://192.168.100.59:443 might refer to the same URL as your repository server at, for example: https://foobar.com:443 the SSL handshake will fail as the hostnames don't match.

This issue persists for any case where your repository URL's hostname does not match that responded by the SVN server's certificate.

I imply you are using a self-signed certificate via the VisualSVN certificate generation tool. To solve, regenerate a new certificate and make sure the hostname matches that of your real hostname. That should fix your issues.

Please note: You're still gonna get that first dialog box with warning that you're using a certificate thats not verified/valid but you shouldn't get that second dialog. Also, make sure both client and server SVN versions are the same, differing SVN versions cause great havoc.

Edit:

Sorry, I read the error backwards, your certificate hostname is apparently 571458-tools1 when it should be 192.168.100.59 if you want to access it. Follow the same certificate regeneration steps above but use the hostname of 192.168.100.59 instead of 571458-tools1.

Please note that this will then allow SSL/TLS connections to work only when using the internal IP directly.

initramfs
  • 8,275
  • 2
  • 36
  • 58
  • 1.8.8 does not have more strict requirements for certificates. There should be no change for this for users on the Mac with 1.8.8. Windows was changed so that it could use the system list of trusted root certificates. OS X still does not use the list of trusted certificates in the keychain but rather the list of certificates trusted by openssl, which is usually nothing on the Mac. That's the reason for that first prompt. – Ben Reser Mar 01 '14 at 01:53
  • @BenReser Okay, thanks for the information on that. But it is quite evident OP is using a self-signed certificate, whether mac uses its keychain (or was it keyring?) certificates or openssl's is irrelevant. The first prompt is caused by a whole group of failures: untrusted, mismatching domain and some general "unknown error". – initramfs Mar 01 '14 at 02:00
  • CPU Terminator, thanks for the advice but it doesn't seem to help because I'm accessing behind a vpn so the numeric IP is the only hostname I have for the target machine. Using the full 571458-tools1.mycompanyname.com URL gives a completely different IP. I have tried signing the certificate with the numeric IP address only, and there is no difference in results. – Daniel Widdis Mar 01 '14 at 02:03
  • @DanielWiddis Are you saying you are accessing the repository with the literal IP mentioned in the certificate? Because svn apparently thinks you are not. The whole basis of SSL/TLS is to be (relatively) hard to tamper with. If your VPN allows for other SSL/TLS traffic to go through I can't imagine how it would be an issue. – initramfs Mar 01 '14 at 02:07
  • @CPU Terminator, yes, I access directly with IP. $ svn info Path: . Working Copy Root Path: /Users/danielwiddis/Documents/workspace/Ascent-JPPF URL: https://192.168.100.59/svn/Ascent/Ascent-JPPF Relative URL: ^/Ascent-JPPF Repository Root: https://192.168.100.59/svn/Ascent I have tried signing the certificate using the numeric IP as the hostname, no go. – Daniel Widdis Mar 01 '14 at 02:10
  • @DanielWiddis Did you accidentally include the port number or `https://`? The hostname should be only the numerical IP. Also, after using the numerical IP directly, does it still show `The certificate hostname does not match.`? – initramfs Mar 01 '14 at 02:15
  • Yes, I tried only the IP. I have also tried it with the port number, and just about every other variation I can think of as a troubleshooting effort. (Fortunately, VisualSVN Server makes changing certificates a trivial exercise... just wish I could find the combo that works!) – Daniel Widdis Mar 01 '14 at 02:20
  • Just tried it again.... $ svn update Updating '.': Error validating server certificate for 'https://192.168.100.59:443': - The certificate has an unknown error. Certificate information: - Hostname: 192.168.100.59 - Valid: from Mar 1 02:21:16 2014 GMT until Feb 27 02:21:16 2024 GMT - Issuer: - Fingerprint: BE:C4:65:B6:0E:BD:5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E (R)eject or accept (t)emporarily? t At revision 46. – Daniel Widdis Mar 01 '14 at 02:22
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/48740/discussion-between-cpu-terminator-and-daniel-widdis) – initramfs Mar 01 '14 at 02:25
  • To close the loop, chat discussion confirmed that changing the hostname resolved that error, but the "unknown error" remains. Question is still open. – Daniel Widdis Mar 01 '14 at 02:50
  • 2
    FYI Subversion's serf HTTP Library support does not support validating certificates with ips in them. Neon did (was the default up to 1.7.x and is no longer even included in 1.8.x). I don't think that's the issue here, but worth mentioning. – Ben Reser Mar 01 '14 at 03:20
  • Ben, thanks for the comments. I see you're a member of the subversion development team. I was able to revert to 1.8.5 and the problem went away. Let me know if there's a way to work with you to determine what's different in 1.8.8 for my setup. – Daniel Widdis Mar 01 '14 at 03:57
2

The certificate has an unknown error could be a certificate chain problem. I encountered this after upgrading from Windows SVN 1.8.3 to 1.8.7. You can look for this by running this command: echo | openssl s_client -connect host:443

e.g.

Certificate chain
 0 s:/[redacted]/
   i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The error here is that 1's subject does not match 0's issuer. Fix the certificate chain on the server.

Kevin Smyth
  • 1,892
  • 21
  • 22
  • 1
    The error was a result of the self-signed certificate generating a new type of error in subversion 1.8.8 which was not properly handled in versions of serf before 1.3.4, and there were a few days of overlap during which I updated my ports. Everything is now up to date and works. – Daniel Widdis Jun 06 '14 at 23:21
1

I was able to figure out how to revert to subversion 1.8.5 via this link:

trac.macports.org/wiki/howto/InstallingOlderPort

Reverting to 1.8.5 resolved the problem. I'll pursue further troubleshooting of what's up with 1.8.8 directly with subversion developers.

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63