当 bettercodes.org 在 9 月份消失时，我将我的私人仓库转移到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
它没有给我永久接受的选项，就像我前几次搜索所显示的那样。我猜是因为“未知错误”。
每https://serverfault.com/questions/27006/svn-wont-accept-my-invalid-certificate，我尝试更新 [global]:ssl-authority-files 以包含来自 assembla 的证书，并将 ssl-trust-default-ca 设置为 true。它仍然出现该错误。
当那不起作用时，我深入研究了 ~/.subversion/auth/svn.ssl.server/___ 文件的格式，弄清楚了如何从 SSL 证书中获取相同的名称和编码到该文件中，就好像我说过“(p)ermanent”一样……但它仍然每次都会给出相同的错误和提示。
随着时间的推移，我浏览了其他 stackexchange 答案，这些答案向我指出了诸如从 curl.haxx.se 下载 cacert.pem 并将其添加到 ssl-authority-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 查看了 assembla 的证书，并与上面错误中提到的 godaddy 证书列表进行了比较，并找出了我认为我需要的证书：我下载了 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 的 Class 2 证书颁发机构是自签名的。但我认为这没问题，因为我明确告诉 svn 信任该证书。
那么，我还能做些什么来让颠覆不再要求我暂时接受该证书？还是每次更新、提交等时我都不得不按 t？
2015 年 11 月 23 日编辑
根据评论，我查找了“某种错误（除代码 19 之外）”，但无法重现它。我想一定是我的记忆将 svn 中的“未知错误”与 openssl 中更详细的代码 19 结合起来了。因此，在这方面没有新信息。
我尝试访问其他网络上我可以访问的一些其他 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)
当我尝试连接到 assembla 上的 repo 时，它不会抱怨证书。因此该机器没有证书链问题。显然，它实际上信任 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 年 12 月 4 日编辑
我找不到它的中央证书位置（没有 /etc/ssl 或 /etc/pki 目录）。目前，我可能没有太多其他办法可以消除该错误。
答案1
我不建议将其用于任何严肃的用途，但您可以在标准输入中简单地提供“t”：
svn update . <<< t
其他选择是使用--信任服务器证书：
svn --non-interactive --trust-server-cert update .
它应该适合你的 SVN 版本，它是在 1.6 中添加的。
另请参阅此帖子，其中有一篇不错的预计提供的解决方案： https://serverfault.com/questions/37929/how-do-you-accept-an-ssl-certificate-through-the-svn-command-line
答案2
部分答案仅限openssl s_client verify error 19：根据您使用的 OpenSSL 版本和构建，它可能会“拒绝”该证书，即使 CA 根位于本地信任库中；请参阅SSL 根 CA 证书无法识别，尽管它存在于信任库中。为什么？。
如果你的“工作正常”系统是 RedHat 系列，请检查版本包括补丁例如 1.0.1e-42.el6或rpm等yum，不是其输出的openssl version上游版本前修补。在“问题”系统上，如果版本看起来很旧或可能如此，请查看openssl version -d并尝试-CApath使用该目录，看看它是否包含名称或链接大多为十六进制的单个文件，或者-CAfile使用该目录加号/cert.pem（如果存在）——即使这些在逻辑上应该是多余的。
但这个问题不会产生影响，svn所以它对解决你的根本问题没有帮助。