Когда в сентябре пропал 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-полномочий-файлы, чтобы включить сертификат из сборки и установить ssl-trust -по-ка к истине. Это все еще дает эту ошибку.
Когда это не сработало, я покопался в формате файлов ~/.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). На данный момент, вероятно, на этой конкретной машине я ничего не могу сделать, чтобы устранить ошибку.