2012-02-13 101 views
17

我正在管理基於Subversion的構建系統,我們使用自簽名ssl作爲服務器。所以有時候,我們會因爲新機器的添加而導致構建失敗,並且無法檢出,因爲這是第一次讓機器聯繫svn服務器。在顛覆中繞過ssl證書驗證

的錯誤信息是這樣的:

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? 

我通常需要的是像--insecure參數捲曲。現在,我們的解決方法是隻做一些簡單的svn命令,以便我們可以永久回答問題並解決問題......至少在ssl證書再次更改/更新或構建完成另一個新的機。

有人解決了這個問題嗎?

感謝提前:)

回答

21

我想你有兩個選擇;拋出船外的所有注意事項和設置在命令行信任服務器證書和非交互式:

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.First檢查和驗證,如果證書已改變之前到svn調用 - 然後或者中止非常乾淨,讓人類進行判斷調用,或者髒東西 - 就像使用-showcert更新〜/ .subversion中的已知證書一樣。

在任何情況下 - 的不直觀的魔法位上的文件在〜/的.subversion/auth /中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 

,然後可以使用OpenSSL的s_client.First與-CApath或與證書驗證,看它是否已經改變和/或使用-showcert交叉檢查。 (注意:如果需要,替代perl -e'使用MIME :: Base64;打印decode_base64(join(「」,));「)。

+0

謝謝德克。正是我正在尋找的:) – icasimpan 2012-02-20 08:30:35

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

有兩種可能的情況:證書是不可信的,但有效的(即,例如有效的自簽名證書),或證書無效(當您通過IP或訪問的計算機在局域網上,如從FQDN的局域網外部發出,並且該機器具有頒發給其符號名稱的證書)。即使使用--trust-server-certificate選項,svn客戶端也不會信任第二種類型的證書。在第二種情況下,我能想到的唯一選擇是使用主機文件條目將該機器的IP別名到其內部名稱。

插圖時的VisualSVN與所有默認選項安裝和生成證書機器的符號名稱,它發現,我曾經面對的場景二:

LAN機器名MACHINE1運行SVN服務器,它有一個證書安裝後發給MACHINE1。您嘗試通過其IP地址訪問SVN並獲取無效的證書錯誤。

如果可以通過FQDN從局域網外訪問MACHINE1,例如svn.domain.com並且您正在連接到FQDN,那麼您也會遇到該錯誤。

在這兩種情況下,svn都會拋出無效證書錯誤。

您可以添加到hosts文件中的條目映射(取決於你在哪裏訪問它LAN或外部)的名稱證書的機器的IP地址發出來:

123.45.67.89 MACHINE1 

和訪問SVN通過https://machine1/svn/來規避這種情況。