21:32 - Wednesday, 23 April 2014

SVN: Error Validating Server Certificate For Svn Hook Linux

#Topics: errors validating the server certificate rapid svn windows,subversion Error validating server certificate for,svn error certs,svn Error validating server certificate

I managed to setup a SVN (over SSL) server and TortoiseSVN client on Win.

I made a Post-Commit Hook for test project. The Post-Commit will update the web dir so the App in PHP can be executed with the newest version.

It all works when done over shell. The only problem is, when i commit the changes over the client in Win the change is commited but HOOK throws error

post-commit hook failed (exit code 1) with output:Error validating server certificate for 'https://SERVER_IP: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: DEVSRVR - Valid: from Fri, 28 Jan 2011 09:22:45 GMT until Sat, 28 Jan 2012 09:22:45 GMT - Issuer: PHP, SS, SS, SRB - Fingerprint: 5f:d0:50:d6:dd:a6:d4:64:a5:ac:3a:4b:7c:7d:33:e3:75:dd:23:9f(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://SERVER_IP/svn/myproject/trunk': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://SERVER_IP)

This is the default behavior of SVN when working with a certificate it does not trust. Take a look at the SSL Certificate Management section in “Version Control with Subversion“.

If the client receives a server
certificate, it needs to verify that
it trusts the certificate: is the
server really who it claims to be? The
OpenSSL library does this by examining
the signer of the server certificate,
or certifying authority (CA). If
OpenSSL is unable to automatically
trust the CA, or if some other problem
occurs (such as an expired certificate
or hostname mismatch), the Subversion
command-line client will ask you
whether you want to trust the server
certificate anyway.

This dialogue should look familiar;
it’s essentially the same question
you’ve probably seen coming from your
web browser (which is just another
HTTP client like Subversion). If you
choose the (p)ermanent option, the
server certificate will be cached in
your private run-time auth/ area in
just the same way your username and
password are cached (see the section
called “Client Credentials Caching”).
If cached, Subversion will
automatically trust this certificate
in future negotiations.

It looks like the solution is to just run it manually and have it accept the certificate permanently or to set ssl-trust-default-ca to true in your config.

Many OpenSSL installations also have a
pre-defined set of “default” CAs that
are nearly universally trusted. To
make the Subversion client
automatically trust these standard
authorities, set the
ssl-trust-default-ca variable to true.

As @runlevel6 said, you have to accept the certificate with the same user running the hook.

If for some reason you have permission to edit the hook but not for running commands as this user try changing the svn command in the hook temporarily to this:

echo "p" | svn command_that_shows_the_error

If you don’t have an explicit svn command in the hook use this:

echo "p" | svn info http://repositoryurl

Then run it once for it to accept the certificate permanently. I had to do this once because of a cron job that deleted the auth cache and it worked.