Subversion Server SSL certificate verification failed: and other reason(s)

Question

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...

Answer 1

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.

Answer 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.

Answer 3

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.