svnはhttps / ssl証明書を受け入れていません
9月にbettercodes.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-authority-filesを更新してからの証明書を含めようとしましたassemblaを実行し、ssl-trust-default-caをtrueに設定します。それでもそのエラーが発生します。
それがうまくいかなかったとき、私は〜/ .Subversion/auth/svn.ssl.server/___ファイルの形式を掘り下げ、SSL証明書からそのファイルに同じ名前とエンコーディングを取得する方法を考え出しました。私は「（p）ermanent」と言っていましたが、それでも同じエラーが発生し続け、毎回プロンプトが表示されました。
時間の経過とともに、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を使用してアセンブリの証明書を調べ、上記のエラーで言及された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は、GoDaddyのクラス2認証局が自己署名しているためだと思います。しかし、私は特にsvnにその証明書を信頼するように指示したので、それで問題ないと思っていたでしょう。
それで、Subversionにその証明書を一時的に受け入れるように要求するのをやめるために私ができることは他にありますか？それとも、更新やコミットなどのたびにtを押し続けていますか？
2015年11月23日編集
コメントによると、私は「ある種のエラー（コード19以外）」を探しに行きましたが、それを再現することができませんでした。 svnの「unknownerror」とopensslのより詳細なコード19を組み合わせたメモリが必要だと思います。したがって、その面での新しい情報はありません。
他のネットワークでアクセスできる他のLinuxボックスにアクセスしてみました。
1つは、svnがインストールされていなかったが、
# openssl version
OpenSSL 0.9.7m 23 Feb 2007
上記と同じコード19を与えます。
2番目に、私は得ます：
[~]# 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でリポジトリに接続しようとしても、証明書について文句を言うことはありません。そのため、そのマシンには証明書チェーンの問題はありません。どうやら、それは実際にGoDaddyを信頼しています。
https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ から提案された証明書の場所のいくつかを見てください、code：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についてすでに指摘されているもの以外に、opensslの今日の特定のインスタンスがGoDaddyのルート証明書を受け入れる理由を理解するために、どのsvnまたはopenssl設定を探す必要がありますか？しかし、opensslの元のインスタンスは、同じ証明書を見ているときにコード：19を与えます。
2015年12月4日編集
中央の証明書の場所が見つかりませんでした（/ etc/sslまたは/ etc/pkiディレクトリがありません）。この時点で、エラーを排除するためにその特定のマシンでできることはおそらく他にほとんどありません。
深刻な使用にはお勧めしませんが、標準入力に「t」を指定するだけで済みます。
svn update . <<< t
他のオプションは、-trust-server-certを使用することです：
svn --non-interactive --trust-server-cert update .
お使いのSVNバージョンでは問題ないはずです。1.6で追加されています。
このスレッドも参照してください。Niceexpectソリューションが提供されています： https://serverfault.com/questions/37929/how-do -you-accept-an-ssl-certificate-through-the-svn-command-line
openssl s_client verify error 19のみの部分的な回答：使用するOpenSSLのバージョンとビルドによっては、CAルートがローカルのトラストストアにある場合でも証明書を「拒否」する場合があります; SSLルートCA証明書は、トラストストアに存在しますが、認識されません。を参照してください。なぜですか？ 。
「正常に動作する」システムがRedHatファミリの場合は、バージョンを含むパッチを確認してください。 1.0.1e-42.el6rpmまたはyumなど、アップストリームであるopenssl versionの出力ではありませんバージョン before patching。 「問題のある」システムで、バージョンが古いかそうである可能性がある場合は、openssl version -dを確認し、名前またはリンクがほとんど16進数である個々のファイルが含まれている場合は、そのディレクトリで-CApathを試してください。存在する場合は、そのディレクトリと-CAfileを使用して/cert.pemを試してください。 -これらは論理的に冗長である必要がありますが。
ただし、この問題はsvnには影響しないため、根本的な問題には役立ちません。