svn não aceita meu certificado inválido

Question

• Eu tenho um servidor executando o apache com um certificado autoassinado (o servidor) com o subversion conectado em
• Requer um nome de usuário para fazer o checkout ou atualizar a partir do repo.
• Eu tenho um checkout do repositório que estou tentando atualizar em um cron job em dois servidores: servidor e cliente. Nem o trabalho cron funcionará pelo mesmo motivo (tenho quase a mesma configuração em ambos, mas o cliente é mais simples).
• As seguintes estão no cliente, onde há apenas um login: root (eu sei, por favor, me poupe do ridículo)
• eles são ambos gentoo se você acha que importa

erro

Error validating server certificate for 'https://server: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: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

   (R)eject, accept (t)emporarily or accept (p)ermanently? 
svn: OPTIONS of 'https://server/svn/repo': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://server)

Eu sei tudo isso. É por isso que eu segui todos os guias para que o svn aceite automaticamente o certificado:

/root/.subversion/servers

[global]
ssl-authority-files = /root/scripts/server.crt

/root/scripts/server.crt

-----BEGIN CERTIFICATE-----
MIIDejCCAmICCQDibo0twimetjANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJV
UzERMA8GA1UECBMITmV3IFlvcmsxDDAKBgNVBAcTA05ZQzEjMCEGA1UEChMaSGFw
et al
-----END CERTIFICATE-----

/root/scripts/backup.sh

svn up /BACKUP/checkouts/server/ --username tom

E o comando roda bem como root (sem sudo, diretamente como root) sem nenhum aviso para confirmar um certificado (ele tinha anteriormente, mas eu escolhi p para aceitar permanentemente).

Alguém sabe por que meu script não funciona? Tem me incomodado nos últimos meses.

** Editar: ** Demorei um pouco para voltar a isso, e segui o conselho de David, mas ainda não funciona. Agora o erro é:

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: server
 - Valid: from Sat, 20 Jun 2009 14:10:45 GMT until Mon, 20 Jun 2011 14:10:45 GMT
 - Issuer: Fake Company, New York, US
 - Fingerprint: 1a:c6:9c:eb:62:9e:e1:05:d9:d3:ac:01:f4:35:dc:00:14:48:e5:39
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://server/svn/folder': Server certificate verification failed: issuer is not trusted (https://server)

    

Answer 1

Error validating server certificate for 'https://server: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: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

O problema é que o seu certificado não corresponde ao nome do host do seu servidor. Você precisa do campo CN no certificado para corresponder ao seu nome de host. No seu caso, o seu nome de host é "servidor" e o CN do seu certificado é "Tom". Você precisa gerar novamente seu certificado com o valor CN correto.

    

Answer 2

Uma coisa a notar - muitas tarefas agendadas são executadas com uma HOME diferente (por exemplo, / etc / crontab (cron.daily etc) configura HOME = /) para que tenha um arquivo .subversion diferente. Apenas nos mordeu aqui e houve uma /.subversion tree sem o certificado aceito. Definindo HOME corretamente no script cron corrigido.

    

Answer 3

Você tentou definir ssl-trust-default-ca para true ? Eu não sei se vai resolver o seu problema, mas eu vi essa recomendação em Controle de versão com o Subversion livro.

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 4

Existem algumas soluções para contornar o problema que me vem à mente. Primeiro, você pode criar um novo host virtual webdav no Apache que não use este certificado (http simples). Como alternativa, você pode usar o método de acesso svn + ssh e a autenticação de chave privada para a tarefa cron (pode ser um risco de segurança).

Eu só seguiria esse caminho se você não puder corrigir os problemas com o certificado ou se não estiver vinculado ao acesso https webdav.

    

Answer 5

As respostas a essa pergunta me ajudaram a reunir as peças necessárias para resolver um problema similar que eu estava tendo. Isso é apenas para pré-montar as peças para outros noobs linux como eu.

para testar o script executado por meio do uso do cron

sudo su

em vez do que eu estava usando

sudo -s

caso contrário, o diretório inicial e outras variáveis não serão como quando ele é executado pelo cron (root)

segundo, não use "--no-auth-cache". Se você adicionar esse switch, nunca poderá aceitar permanentemente o certificado.

usando o acima, eu consegui rodar o script uma vez via sudo su, aceitar o certificado permanentemente e as cron cronicas subseqüentes funcionaram.

    

Answer 6

você pode simplesmente:

echo t | svn update --username yourusername--password yourpassword --no-auth-cache /local.repository/path 2>/dev/null

    

Answer 7

Você pode tentar validar o certificado manualmente :

$ openssl x509 -noout -fingerprint -in cert.pub
MD5 Fingerprint=0D:89:07:D6:4F:BC:84:2E:2E:14:C2:DA:D4:3B:D5:7C

    

Answer 8

Coloque isso no seu script:

# svn up /BACKUP/checkouts/server/ --username tom –config-dir /xyz/zyx

config-dir pode ser qualquer coisa em que você queira armazenar as informações do certificado. Antes de executá-lo no cron, execute-o manualmente e aceite o certificado permanentemente, usando "p".

Uma vez aceito, execute-o no cron e acredito que funcionará como um encanto.

Há mais uma opção (se a opção anterior não funcionar por acaso), o que é um pouco arriscado em outros ambientes, mas no seu ambiente, tudo bem. Use o script algo assim:

# svn up /BACKUP/checkouts/server/ --username tom --non-interactive –-trust-server-cert

Isso simplesmente aceitará o certificado sem incomodar. Isso não é aconselhado no ambiente de produção porque isso é um risco de segurança, mas no seu caso, onde você está usando um certificado próprio, você pode usá-lo.

Fonte: GeekRide