SVN: Erro ao validar o certificado do servidor para o svn hook linux

Question

Consegui configurar um servidor SVN (sobre SSL) e um cliente TortoiseSVN no Win.

Eu fiz um gancho de pós-commit para o projeto de teste. O Post-Commit atualizará o diretório web para que o App em PHP possa ser executado com a versão mais recente.

Tudo funciona quando feito em shell. O único problema é que, quando eu faço as alterações no cliente no Win, a alteração é confirmada, mas o HOOK gera um erro

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)

    

Answer 1

Esse é o comportamento padrão do SVN ao trabalhar com um certificado em que ele não confia. Dê uma olhada na seção SSL Certificate Management em " Controle de Versão com 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.

Parece que a solução é apenas executá-lo manualmente e aceitar o certificado permanentemente ou definir ssl-trust-default-ca como true em sua configuração.

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.

    

Answer 2

Como disse @ runlevel6, você precisa aceitar o certificado com o mesmo usuário executando o gancho.

Se por algum motivo você tiver permissão para editar o hook mas não para rodar comandos como este usuário tente alterar temporariamente o comando svn no hook:

echo "p" | svn command_that_shows_the_error

Se você não tem um comando svn explícito no hook use:

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

Em seguida, execute-o uma vez para aceitar o certificado permanentemente. Eu tive que fazer isso uma vez por causa de um trabalho cron que apagou o cache de autenticação e funcionou.