SVN не принимает сертификат https / ssl

Когда в сентябре пропал bestcodes.org, я переместил свой личный репозиторий на https://subversion.assembla.com/ , Он работает отлично, за исключением того факта, что мне приходится временно принимать сертификат каждый раз, когда я взаимодействую с сервером.

> 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

Это не дает мне возможность принять (p) по ошибке, как показали мои первые несколько поисков. Я предполагаю, что это из-за "неизвестной ошибки".

в https://serverfault.com/questions/27006/svn-wont-accept-my-invalid-certificate Я попытался обновить [global]: ssl-author-files, чтобы включить сертификат из Assembly, и установить для ssl-trust-default-ca значение true. Это все еще дает эту ошибку.

Когда это не сработало, я покопался в формате файлов ~ / .subversion / auth / svn.ssl.server / ___ и выяснил, как получить то же имя и кодировку из сертификата SSL в этот файл, как будто Я сказал "(p) ermanent" ... но он все еще продолжал давать ту же самую ошибку и подсказывать каждый раз.

Со временем я перебирал ответы на другие вопросы об обмене стеками, которые указывали мне на такие вещи, как загрузка cacert.pem из curl.haxx.se и добавление этого в ssl-author-files: когда я это пробую, я получаю:

svn: E125009: Unable to connect to a repository at URL 'https://subversion.assembla.com/svn/[...my repo path...]'
svn: E125009: Invalid config: unable to load certificate file '/users/jonespet/.subversion/auth/ssl.certs/cacerts.pem'

Я взял cacerts.pem обратно, потому что это делало вещи еще хуже, а не лучше. :-(

Поэтому я посмотрел на сертификат для ассембла с использованием firefox, сравнил со списком сертификатов godaddy, упомянутых в приведенной выше ошибке, и выяснил, какие из них, по моему мнению, мне нужны: я скачал gdroot-g2.crt и gdig2.crt, а это не так не поможет

С помощью Что Subversion использует для своего списка CA? , Я старался

> openssl s_client -connect subversion.assembla.com:443 -showcerts
...
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.assembla.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.assembla.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 4910 bytes and written 468 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    ...
    Verify return code: 19 (self signed certificate in certificate chain)
---

Я предполагаю, что код возврата 19 связан с тем, что сертификационный центр Go Daddy класса 2 самоподписан. Но я бы подумал, что все будет в порядке, поскольку я специально сказал svn доверять этому сертификату.

Итак, могу ли я что-то еще сделать, чтобы заставить подрывную деятельность прекратить требовать от меня временного принятия этого сертификата? Или я застрял, нажимая t для каждого обновления, фиксации и т. Д.?

ИЗМЕНЕНИЯ 2015-НОЯ-23

Согласно комментариям, я искал «какую-то ошибку (кроме кода 19)», но не смог ее воспроизвести. Я думаю, что моя память объединяет «неизвестную ошибку» из SVN с более подробным кодом 19 из openssl. Так что никакой новой информации на этот счет нет.

Я попытался перейти на другие Linux-боксы, к которым у меня есть доступ в других сетях.

С одной стороны, он не был установлен SVN, но

# openssl version
OpenSSL 0.9.7m 23 Feb 2007

дает тот же код 19, что и выше.

На втором я получаю:

[~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[~]# svn --version
svn, version 1.7.4 (r1295709)
   compiled Apr  5 2012, 16:46:24
[~]# openssl s_client -connect subversion.assembla.com:443 -showcerts
CONNECTED(00000003)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.assembla.com
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.assembla.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.assembla.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5439 bytes and written 375 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: D5163A837AE5DEAFA2ED82B437F560A87DC7146FE819D9410B97174FAD7E2A67
    Session-ID-ctx:
    Master-Key: E4CCC925DC619A507ADAEEA688BD018A4419A0499C246764D9419542C1BF20F5A4C42B41FC6A776AD33915C20A83149B
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - aa ad c7 b3 f2 f1 1e 77-9b 4f f6 23 73 3b 75 70   .......w.O.#s;up
    0010 - dd bb 03 6c 96 31 b4 07-b0 55 b7 56 2f 32 c8 e5   ...l.1...U.V/2..
    0020 - da 46 06 27 53 79 18 a3-6d a4 8b f2 4c b1 8b e0   .F.'Sy..m...L...
    0030 - a2 04 ba 46 95 bb 3e c1-d3 72 69 59 01 18 2b 1c   ...F..>..riY..+.
    0040 - ba 5d dd ab 96 74 6e 01-db a2 96 54 75 de 4b f6   .]...tn....Tu.K.
    0050 - db ae c3 91 e4 fb fb 88-aa e3 f5 e1 bd bd 02 c8   ................
    0060 - c7 ef 54 63 2f d3 ae 4d-14 6b 47 fa 78 13 06 7f   ..Tc/..M.kG.x...
    0070 - a9 ba 31 23 b2 bf 6e 92-05 c3 35 ce 93 5f 2f 2e   ..1#..n...5.._/.
    0080 - 03 b3 f9 e7 f4 56 ed e7-c2 20 d9 65 8e b4 e2 e4   .....V... .e....
    0090 - 38 b6 e5 78 c0 af f8 12-ca 32 03 15 e2 a9 2a 4e   8..x.....2....*N
    00a0 - ec 62 6b 71 c1 dd 66 4a-96 1b f2 e9 e2 5d 86 96   .bkq..fJ.....]..
    00b0 - c2 3c 71 13 00 b3 16 f8-fd 45 7b 0d 2c aa 8f 6c   .<q......E{.,..l

    Start Time: 1448304537
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

И когда я пытаюсь подключиться к своему репо на ассембле, он не жалуется на сертификат. Так что у этой машины нет проблем с цепочкой сертификатов. Видимо, это на самом деле доверяет GoDaddy.

Глядя на некоторые из предлагаемых мест сертификатов от https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ , на машине, которая дает код: 0, я нашел

# ls -latr /etc/pki/tls/certs/ca-bundle.*
-rw-r--r-- 2 root root 1066943 Apr 23  2015 /etc/pki/tls/certs/ca-bundle.trust.crt
-rw-r--r-- 2 root root  877042 Apr 23  2015 /etc/pki/tls/certs/ca-bundle.crt

На сегодняшней первой машине, без svn, она имеет другую структуру, но я обнаружил, что у них есть сертификат GoDaddy

# ls -latr /etc/ssl/certs/Go*
lrwxrwxrwx 1 root root 58 Dec  8  2014 /etc/ssl/certs/Go_Daddy_Class_2_CA.pem -> /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt

В следующий раз, когда я буду на машине, где я впервые начал видеть эти проблемы, мне нужно будет поискать хранилище сертификатов в этих различных каталогах и посмотреть, не устарело ли что-то в центральных местах.

Но теперь я думаю, что мне больше всего пригодится: кроме того, что уже было указано для svn, какие настройки svn или openssl я должен искать, чтобы выяснить, почему конкретный сегодняшний экземпляр openssl принимает корневой сертификат GoDaddy, но оригинальный экземпляр openssl дает ему код: 19, когда они смотрят на один и тот же сертификат.

РЕДАКТИРОВАТЬ 2015-Dec-04

Я не смог найти его центральное местоположение сертификата (без каталогов / etc / ssl или / etc / pki). На данный момент, вероятно, на этой конкретной машине я ничего не могу сделать, чтобы устранить ошибку.

ssl svn certificate https PeterCJ
источник

Частичный ответ за openssl s_client verify error 19 только: в зависимости от используемых вами версий и сборок OpenSSL он может «отклонить» сертификат, даже если корень CA находится в локальном хранилище доверенных сертификатов; увидеть Сертификат корневого ЦС SSL не распознается, хотя присутствует в хранилище доверенных сертификатов. Зачем? ,

Если ваша система работает нормально, это семейство RedHat, проверьте версию в том числе патчи например 1.0.1e -42.el6 в rpm или же yum и т. д., а не вывод openssl version которая является основной версией до внесение исправлений. На «беде» системы, если версия выглядит старой или, возможно, так, посмотрите на openssl version -d и попробовать -CApath с этим каталогом, если он содержит отдельные файлы с именами или ссылками в основном в шестнадцатеричном виде, или -CAfile с этим каталогом плюс /cert.pem если он существует - даже если они логически должны быть избыточными.

Но эта проблема не повлияет svn так что это не поможет с вашей основной проблемой.

dave_thompson_085
источник

К несчастью, openssl s_client -CAfile /usr/share/ssl/cert.pem -connect subversion.assembla.com:443 -showcerts по-прежнему выдает ту же ошибку 19, что и вариант CApath. Но я обнаружил, что файл certs / ca-bundle.crt относится к 2007 году. Когда я пытался указать CAfile на более свежий пакет, который я скачал, он по-прежнему выдает ошибку 19. Я думаю, не имея root-доступа, я не думаю, что есть многое я мог сделать. Но я узнал немного больше о конфигурации и некоторых параметрах отладки, так что спасибо за ваш ответ.

PeterCJ

SVN не принимает сертификат https / ssl

Ответы: