Debian – SVN: Error validating server certificate for svn hook linux

debianhookssl-certificatesvn

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)

Best Answer

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.

Related Topic