3

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)
Improve this question

2 Answers 2

Reset to default
2

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.

Improve this answer
3
  • How can I accept the cert. That fubar.bin is executed by Post-Commit bash, I can only see the Error in the Commit - TortoiseSVN window.
    – Dr Casper Black
    Feb 3, 2011 at 14:39
  • if you run svn list https://repourl from your server does it prompt you to accept the certificate?
    – runlevelsix
    Feb 3, 2011 at 17:07
  • @Dr Casper Black: you need to accept the certificate as the user running the hook.
    – David Schmitt
    May 2, 2011 at 12:09
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .