Quando o bettercodes.org desapareceu em setembro, mudei meu repositório privado para o link . Está funcionando muito bem, exceto pelo fato de que eu tenho que aceitar temporariamente o certificado toda vez que eu interajo com o servidor.
> svn --version
svn, version 1.8.4 (r1534716)
> svn update .
Updating '.':
Error validating server certificate for 'https://subversion.assembla.com:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate has an unknown error.
Certificate information:
- Hostname: *.assembla.com
- Valid: from Apr 16 13:31:17 2014 GMT until Mar 24 19:30:40 2016 GMT
- Issuer: http://certs.godaddy.com/repository/, GoDaddy.com, Inc., Scottsdale, Arizona, US
- Fingerprint: EC:9F:9D:B2:39:E1:34:81:7B:27:F6:51:30:8B:AC:41:5B:62:09:19
(R)eject or accept (t)emporarily? t
Não me dá a opção de aceitar (p) de forma permanente, como as minhas primeiras pesquisas indicaram que seria. Eu estou supondo que é por causa do "erro desconhecido".
Por link , tentei atualizar [global]: ssl- arquivos de autoridade para incluir o certificado de assembla e defina ssl-trust-default-ca como true. Ainda dá esse erro.
Quando isso não funcionou, eu procurei no formato dos arquivos ~ / .subversion / auth / svn.ssl.server /
Eu não recomendaria isso para nenhum uso sério, mas você pode simplesmente fornecer o 't' na entrada padrão:
svn update . <<< t
Outra opção seria usar - trust-server-cert :
svn --non-interactive --trust-server-cert update .
Deve estar OK para a sua versão do SVN, é adicionado em 1.6.
Veja também este tópico, há uma boa solução expect fornecida: link
Resposta parcial para openssl s_client verify error 19 apenas: dependendo das versões do OpenSSL, e as compilações usadas podem "rejeitar" o certificado, mesmo que a raiz da CA esteja no truststore local; consulte O certificado de CA da Raiz SSL é não reconhecido, embora presente no truststore. Por quê?
Se o seu sistema "funciona bem" for da família RedHat, verifique a versão incluindo patches 1.0.1e -42.el6 em rpm ou yum etc, não a saída de openssl version , que é a versão upstream anterior patch. No "problema"
sistema (s) se a versão parece antiga ou possivelmente, olhe para openssl version -d e tente -CApath com esse diretório se ele contiver arquivos individuais com nomes ou links principalmente em hexadecimal, ou -CAfile com esse diretório mais /cert.pem se existir - mesmo que estes sejam logicamente redundantes.
Mas esse problema não afetaria svn , por isso não ajuda em seu problema subjacente.
Tags ssl svn https certificate