2012-02-13 10 views
17

私はSubversionベースのビルドシステムを管理しており、サーバーには自己署名付きSSLを使用しています。だから時々、新しいマシンが追加されているため、マシンがsvnサーバーに接続するのは初めてのため、チェックアウトできません。subversionでssl証明書の検証をバイパスします

エラーメッセージは次のようである:私は一般的にカールする--insecureパラメータのようなものである必要がある何

icasimpan ~$ svn ls https://scm.myserver.com/trunk 
Error validating server certificate for 'https://scm.myserver.com:443': 
- The certificate is not issued by a trusted authority. Use the 
    fingerprint to validate the certificate manually! 
Certificate information: 
- Hostname: scm.myserver.com 
- Valid: from Mon, 05 Dec 2011 00:00:00 GMT until Tue, 11 Dec 2012 23:59:59 GMT 
- Issuer: Terms of use at https://www.verisign.com/rpa (c)10, VeriSign Trust Network, VeriSign, Inc., US 
- Fingerprint: c0:69:f6:67:8d:1f:d2:85:c1:94:9f:59:8e:81:cc:81:3d:1e:44:28 
(R)eject, accept (t)emporarily or accept (p)ermanently? 

。今すぐ回避するには、いくつかのシンプルなsvnコマンドを実行して、 "永久に"答えることができ、問題は解決されます...少なくとも、SSL証明書が変更/更新されるか、ビルドが別の新しい機械。

誰かがこの問題を解決しましたか?事前に

感謝:)

答えて

21

私は次の2つのオプションを持っていると思います。船外にすべての注意を投げると信頼サーバー証明書およびコマンドラインから非対話型の設定:

svn help co 
.... snip.... 
--non-interactive  : do no interactive prompting 
--trust-server-cert  : accept unknown SSL server certificates without 
         prompting (but only with '--non-interactive') 

およびその他のオプションは、証明書が前変更されているかどうかを確認し、検証するために-showcertsでのopenssl s_clientのようなものを使用することですsvnコールに送信してから、非常にきれいに中断して、人間が判断コールを行うようにするか、または汚れた何かを~showcertを使用して〜/ .subversionの既知の証明書を更新するようにします。いずれの場合も

- 非直観魔法のビットは、〜/ .subversion /認証/ svn.ssl.serverに/ <serverrecord>内のファイルにある - あなたが必要とする証明書の情報を抽出するには:

cat <serverrecord> | grep ^MII | base64decode | openssl x509 -text -inform DER 

cat <serverrecord> | grep ^MII | base64decode | openssl x509 -text -inform DER -noout - out current-cert.pem 

、その後-capathでのopenssl s_clientを使用するか、それが変更されているかどうかを確認および/またはクロスチェックに-showcert使用すること証明書で確認することができるようなもの。 (注:perl -e 'の代わりにMIME :: Base64を使用する;必要に応じてbase64decodeのためにdecode_base64(join( ""、));を出力する。

+0

ありがとうございました。ちょうど私が探しているもの:) – icasimpan

1

もう1つの選択肢はexpectを使用することです。 expectを使用すると、証明書を受け入れるユーザーをシミュレートできます。それ以外のオプションでは動作しません。私はこれを作成して、Dockerfileのsvnからコードをダウンロードできるようにしました。

#!/usr/bin/expect -f 

set svn_username [lindex $argv 0] 
set svn_password [lindex $argv 1] 
set svn_url [lindex $argv 2] 

spawn svn --username=${svn_username} --password=${svn_password} list ${svn_url} 
expect "(R)eject, accept (t)emporarily or accept (p)ermanently? " 
send -- "p\r" 
expect "Store password unencrypted (yes/no)? " 
send "no\r" 
expect -re "[email protected]*:\/#" 
0

2つのシナリオがあります。証明書は信頼されていないが、有効である(すなわち、例えば有効な自己署名証明書)、または証明書が無効である(たとえば、あなたがIPたりして、LAN上のマシンにアクセスしている場合などは、あなたのLANの外からFQDNで送信され、そのマシンはその象徴的な名前に発行された証明書を持っています)。 --trust-server-certificateオプションを使用していても、svnクライアントは2番目のタイプの証明書を信頼しません。第2のシナリオでは、あなたが考えることができる唯一のオプションは、hostsファイルエントリを使用してそのマシンのIPをその内部名にエイリアスすることです。

LANマシン名MACHINE1は、SVNサーバを実行し、それが証明書を持っていますVisualSVNはすべてデフォルトのオプションでインストールし、それが発見されたことをマシンのシンボリック名に証明書を作成したとき、私はかつて直面したシナリオ2の

イラストMACHINE1に発行されたものです。あなたは、そのIPアドレスと無効な証明書エラーを取得してSVNにアクセスしようとしています。

MACHINE1がFQDN(例:svn.domain.com)でLAN外からアクセス可能で、FQDNに接続している場合は、そのエラーが発生します。

どちらの場合でも、svnは無効な証明書エラーをスローします。

123.45.67.89 MACHINE1 

とアクセスSVN:あなたが名前の証明書にマシンのIPアドレス(あなたがからそれをアクセスしている場所に応じてLANまたは外部)をマップするためにhostsファイルにエントリを追加することができます

はに発行されましたこの状況を回避するためにhttps://machine1/svn/を経由します。