根證書含義 - 孤舟蓑笠翁收苏，獨釣寒江雪
- 博客頻道 - CSDN.NET?
本文想簡單談?wù)勀莻€所謂的“根證書”水慨。在訪問鐵道部網(wǎng)上售票官網(wǎng) www.12306.cn 后间校，有一個醒目的提示肛跌，為保證順暢購票刊棕，需要下載安裝根證書个曙。那么什么是根證書锈嫩？為什么買火車票的時候需要下載和安裝受楼，在淘寶等在線交易網(wǎng)站購物時候為什么就不需要這樣做？
今年開始呼寸，人民群眾們終于可以通過互聯(lián)網(wǎng)購買火車票了艳汽。雖然說在線買的難度不比以往排隊購買低多少，但這總算是一次值得鼓勵的嘗試对雪。不過在線購票系統(tǒng)一經(jīng)退出河狐，在技術(shù)上就已經(jīng)被人批得體無完膚。
為了確保安全瑟捣，很多涉及在線交易的網(wǎng)站馋艺，例如網(wǎng)上銀行、購物網(wǎng)站等迈套，都會使用SSL技術(shù)對頁面內(nèi)容進行加密捐祠。SSL技術(shù)在這里的主要用途有兩個：
確保網(wǎng)站服務(wù)器和用戶瀏覽器之間的通訊不被竊聽：這一點很好理解。SSL屬于一種公鑰加密體系桑李，簡單來說踱蛀，一個SSL證書分為兩部分：公鑰和私鑰。其中私鑰會被網(wǎng)站所有者妥善保管贵白，并在服務(wù)器端用私鑰將網(wǎng)絡(luò)通訊全部加密率拒；而公鑰會在網(wǎng)上廣為傳播，一個公鑰加密后的數(shù)據(jù)只有用所對應(yīng)的私鑰才能解密禁荒。因此只要SSL證書本身可以保證安全猬膨，那么在訪問網(wǎng)站的時候就可以保證網(wǎng)絡(luò)通訊不被他人所竊取，并且如果有人進行中間人攻擊呛伴，因為沒有相應(yīng)的密鑰寥掐，導(dǎo)致篡改后的數(shù)據(jù)無法通過校驗，因此可以及時察覺磷蜀。
確保網(wǎng)站所宣稱的身份真實可靠：這一點也不難理解召耘。網(wǎng)上有個網(wǎng)站叫做支付寶，可如何保證這個網(wǎng)站就是那個真正的支付寶褐隆，而不是其他人偽造的釣魚網(wǎng)站污它？因此真正的支付寶可以使用SSL證書，這種針對企業(yè)用的證書的申請手續(xù)比較繁瑣庶弃，有一大堆審查流程衫贬，需要提交大量相關(guān)的證明文件，因此可以保證只有真正的某公司才能以這個公司的名義申請證書歇攻，只要申請到證書固惯，就可以確信身份的可靠。此外近些年還有一種更可靠的EVSSL證書缴守。
試試看訪問“https://www.alipay.com”這個域名葬毫，隨后可以看到镇辉，在瀏覽器的地址欄，“Http”協(xié)議后面出現(xiàn)了“s”這個字母贴捡，并且IE地址欄的右側(cè)顯示了一個鎖頭圖標(biāo)忽肛，因此證明該網(wǎng)站是SSL加密的。點擊這個鎖頭圖標(biāo)后烂斋，還可以看到網(wǎng)站所用證書的相關(guān)信息屹逛。
加密功能基本上沒什么需要解釋的，因此下文的重點將放在身份可靠性這塊汛骂。在上圖所示界面上點擊“查看證書”鏈接罕模，隨后可以看到該網(wǎng)站SSL證書的詳情：
上圖顯示的“VeriSign Class 3 International Server CA – G3”是證書頒發(fā)機構(gòu)，而“www.alipay.com”是證書持有人帘瞭。那么到底應(yīng)該怎樣通過這些信息判斷網(wǎng)站是否可靠手销？
在這里一個很通用的規(guī)則是：如果瀏覽器檢測到加密網(wǎng)站所用的證書是正常的，那么地址欄就會顯示為綠色（使用EVSSL證書）或者白色（使用普通SSL證書）图张，這種情況下可以放心地瀏覽該網(wǎng)站锋拖，并提交自己的數(shù)據(jù)确封；如果瀏覽器檢測到網(wǎng)站的證書有問題戳稽，那么地址欄就會顯示為紅色寇钉，提醒我們注意启绰，同時取決于具體情況趴酣，地址欄右側(cè)會顯示有“證書錯誤”按鈕兑凿，而且網(wǎng)站內(nèi)容不會顯示埃碱，取而代之的是瀏覽器的警告信息催蝗】嘟矗基本上主流瀏覽器的最新版本都已經(jīng)具備這樣的功能售貌。
這個過程的基本原理是：假設(shè)我們信任A公司，而A公司信任B公司疫萤，那么我們就可以信任B公司颂跨。很明顯，“www.alipay.com”的證書是“VeriSign
Class 3 International Server CA –
G3”頒發(fā)的扯饶，這表示后者信任前者恒削，可以證明前者的真實身份，但是我們又憑什么信任后者這個證書頒發(fā)機構(gòu)尾序？
上述文字里不止一次提到“信任”一詞钓丰，那么“信任”在這里是什么意思？是否像我們平時講話時說的“我信任他”那樣每币，代表我們相信他是個好人携丁，不會干壞事？其實完全不是這樣兰怠。這里所說的“信任”梦鉴，只是說明證書持有人的身份是真實可靠的李茫，至于持有人用這個證書干什么事情，不在“信任”的范疇內(nèi)尚揣。例如涌矢，網(wǎng)上很多臭名昭著的惡意軟件掖举，現(xiàn)在都帶有數(shù)字證書（倒是很多正規(guī)用途的軟件因為開發(fā)商缺乏安全觀念不帶證書）快骗，同時因為這些數(shù)字證書的“根”都是我們信任的根證書頒發(fā)機構(gòu)，因此塔次，操作系統(tǒng)和瀏覽器是信任這些公司的身份的方篮，但并不代表這些公司的軟件不會干壞事。只要肯花錢励负，任何人都可以在商業(yè)性質(zhì)的證書頒發(fā)機構(gòu)買到直接被我們的系統(tǒng)所信任的證書藕溅。
其實Windows和任何操作系統(tǒng)本身就包含一些受信任證書頒發(fā)機構(gòu)的根證書，要查看這些根證書继榆，可以運行“certmgr.msc”打開證書控制臺巾表，然后從控制臺窗口左側(cè)的控制臺樹中依次進入“證書-當(dāng)前用戶”→“受信任的根證書頒發(fā)機構(gòu)”→“證書”，隨后右側(cè)的窗口中會顯示本機預(yù)置的所有根證書頒發(fā)機構(gòu)略吨，其中就有“CA
– G3”集币，這表示我們信任“CA – G3”，而“CA –
G3”信任“www.alipay.com”翠忠，因此我們可以信任“www.alipay.com”鞠苟。如果從證書控制臺中刪除“CA –
G3”的根證書，表示我們不再信任它秽之，那么它所信任的公司也將不再被我們信任当娱。
按照上文的方法打開證書控制臺，并進入到“不信任的證書”→“證書”節(jié)點后考榨，還會發(fā)現(xiàn)里面列出了多個頒發(fā)給大量知名企業(yè)的證書跨细，例如Microsoft、Google河质、Skype扼鞋、Yahoo等。為什么會不信任這些大牌互聯(lián)網(wǎng)企業(yè)愤诱？就是因為某家根證書頒發(fā)機構(gòu)被黑客攻破云头，導(dǎo)致這些大企業(yè)所用的證書私鑰被竊取。因此為了保證安全淫半，這些被盜證書已經(jīng)被吊銷溃槐。因而將原本被盜的證書都添加到“不信任的證書”節(jié)點下，這樣盜取證書的黑客就算使用這些證書給病毒簽名科吭，偽裝成這些大企業(yè)昏滴，也會因為證書吊銷的緣故不會讓人輕易上當(dāng)猴鲫。這家倒霉的公司就是荷蘭的DigiNotar，該公司因為這次事件現(xiàn)在已經(jīng)破產(chǎn)谣殊，而從中也足以證明證書吊銷機制的重要性拂共。這一點會在下文詳細介紹。微軟已經(jīng)通過KB
2607712補丁將受影響的證書全部設(shè)置為不信任姻几。
這里要重點提出“根證書”這個概念宜狐，全世界具有提供數(shù)字證書業(yè)務(wù)的公司有很多，而Windows自帶的“根證書”很少蛇捌，默認情況下抚恒，我們是如何信任這么多不同公司頒發(fā)的不同證書的？其實這就是“根”這個字的含義络拌，因為可以頒發(fā)證書的公司雖然很多俭驮，但最基本的根證書頒發(fā)機構(gòu)只有有限的幾個，默認情況下都是被操作系統(tǒng)所信任的春贸。那么既然操作系統(tǒng)能信任根證書頒發(fā)機構(gòu)混萝，自然也就可以信任被根證書頒發(fā)機構(gòu)信任的公司，進而可以信任被這些公司所信任的下一級公司萍恕。
如何證明這一點逸嘀？可以單擊上圖中的“查看證書”鏈接，隨后打開“證書”對話框雄坪，切換到“證書路徑”選項卡后厘熟，可以看到下圖所示界面。從該圖中可以看出维哈，整個證書信任鏈的路徑分為三個層次绳姨，最頂層的是我們信任的根證書頒發(fā)機構(gòu)，該機構(gòu)給“International
Server CA –
G3”頒發(fā)了證書阔挠，因此飘庄，我們信任“CA-G3”；隨后“CA-G3”又給“www.alipay.com”頒發(fā)了證書购撼，因此也可以信任“www.alipay.com”跪削。如果“www.alipay.com”再給別人頒發(fā)證書，那么這個人的身份依然可以被我們信任迂求。
而鐵道部的在線訂票網(wǎng)站并沒有走這個一般意義上碾盐，涉及金融交易的商業(yè)化網(wǎng)站都嚴格遵守的方法。也就是說揩局，鐵道部并沒有花錢在商業(yè)性質(zhì)的CA（證書頒發(fā)機構(gòu)）購買受信證書毫玖，他們直接自己給自己頒發(fā)證書。這樣的做法一般主要是用于測試或?qū)W習(xí)等非正式場合，但如果一個商業(yè)化網(wǎng)站想要正式上線運營付枫，通常并不會這樣做烹玉，因為對用戶來說風(fēng)險太大。
當(dāng)我們查看12306.cn 這個網(wǎng)站的證書信息時就會發(fā)現(xiàn)阐滩，這個證書根本沒有一個有效的受信任CA二打，完全是自己給自己發(fā)著玩的。
上圖信息顯示掂榔，該證書的頒發(fā)者以及根證書是“SRCA”继效，不知道這個縮寫代表什么意思，可能是鐵道部內(nèi)部的某個系統(tǒng)衅疙。因為SRCA的身份不被系統(tǒng)自帶的任何一個根證書所信任莲趣，因此12306.cn網(wǎng)站所用的證書默認也不會被任何一個系統(tǒng)所信任鸳慈。因而鐵道部要求安裝根證書的原因饱溢，就是讓訪客將這個證書手工添加到“受信任的根證書頒發(fā)機構(gòu)”節(jié)點下。
很遺憾的是走芋，這種做法雖然很不安全绩郎，可國內(nèi)的大佬們很喜歡使用。例如在我的系統(tǒng)中翁逞，這里就有建行和工行網(wǎng)銀自行添加的根證書肋杖。
那么這種做法除了能省幾個錢之外，對用戶來說有什么危害挖函？
在12306.cn訂票的很多人可能會看到過“該站點安全證書的吊銷信息不可用状植，是否繼續(xù)”這樣的信息。這是什么意思怨喘？
還是以上文那個DigiNotar的例子來說津畸，假設(shè)某個大型CA被攻擊，私鑰被竊取必怜，這時候有兩種方法盡量避免損失：
類似Windows補丁這樣肉拓，由軟件廠商通過發(fā)布更新的方式，將被盜證書強制設(shè)置為不信任梳庆。
使用證書吊銷列表（CRL）暖途。
第一種方式比較好理解，但并不是所有公司都能獲此殊榮膏执。畢竟主流操作系統(tǒng)的用戶數(shù)量龐大驻售，根本不可能針對一個地區(qū)性的，或者規(guī)模很小的公司的被盜證書發(fā)布更新更米，強制不信任欺栗。因此第二種情況就至關(guān)重要了。每個證書中都包含CRL，其實這個可以理解為一個網(wǎng)址纸巷，通過這個網(wǎng)址可以獲得證書吊銷的相關(guān)信息镇草。
因此如果一個小公司通過商業(yè)性CA購買的證書被盜了，只要將相關(guān)信息告知CA瘤旨，這家CA就會將這個證書的內(nèi)容添加到CRL中梯啤。隨后任何一個用戶在執(zhí)行涉及到證書的操作，例如安裝帶有數(shù)字簽名的軟件存哲，或者訪問SSL網(wǎng)站的時候因宇，系統(tǒng)都會通過這個CRL地址檢索吊銷清單，并查看當(dāng)前軟件或網(wǎng)站使用的證書是否位于清單中祟偷。如果不在察滑，就證明這個證書依然是可信任的；如果在修肠，就證明該證書已經(jīng)被盜贺辰，因此軟件或網(wǎng)站存在仿冒的可能。
而因為12306.cn使用了自己給自己頒發(fā)的證書嵌施，因此也就根本無法在自己的證書中包含CRL信息饲化，所以會看到“吊銷信息不可用”的提示，這意味著瀏覽器在告訴你吗伤，你所訪問的網(wǎng)站吃靠，不一定能完全證明其可靠，這可能是真網(wǎng)站足淆，但也有是釣魚網(wǎng)站的可能巢块。
而如果12306.cn的證書私鑰丟失或被盜（看看去年底的大規(guī)模泄密事件，誰敢保證沒有這種可能性）巧号，持有該證書的人想要偽造一個釣魚網(wǎng)站族奢，或者以鐵道部的身份發(fā)布惡意軟件，那真是輕而易舉裂逐，并且鐵道部對此會束手無策歹鱼。
畢竟在線購買火車票的人全都安裝了這個根證書，而該證書根本無法通過CRL吊銷卜高。此外還有一個更重要的問題弥姻，如果盜取該證書的人繼續(xù)使用“SRCA”的身份給其他人以其他身份頒發(fā)證書，例如以銀行或支付中介的名義掺涛，結(jié)果會怎樣庭敦？因為所有在線購買過火車票的人，由于根證書的關(guān)系薪缆，系統(tǒng)已經(jīng)信任SRCA的根證書秧廉，因此這些偽造的證書也會直接被信任伞广。最壞的情況下，所有熱門的SSL加密網(wǎng)站（購物疼电、銀行嚼锄、股票….）要想被偽造都是輕而易舉的。
什么意思呢蔽豺？如果某天你訪問的“支付寶”網(wǎng)站的證書信任鏈是下面這樣区丑，你覺得會是什么后果？
真心希望這種情況永遠不會發(fā)生修陡。同時更加希望國內(nèi)這些大佬們有更多安全意識沧侥，盡快認識到目前這種做法的不足。商業(yè)受信證書雖然需要花錢買魄鸦，但不是太貴宴杀，真的！
當(dāng)然拾因，上述希望可能永遠不會成真旺罢，因此作為一般用戶，如果你已經(jīng)成功在線購買到火車票（恭喜你啊盾致，你要不要去買個彩票試試手氣）主经，那么建議你在“受信任的根證書頒發(fā)機構(gòu)”節(jié)點下將SRCA的根證書徹底刪除荣暮。
Java編程語言的一個杰出之處就在于開源社區(qū)可以以較低的成本或者甚至是免費地提供優(yōu)秀的應(yīng)用程序庭惜。其中一個例子就是Apache Tomcat，它為使用servlet或JSP技術(shù)的開發(fā)提供了一個健壯的Web服務(wù)器∷胨郑現(xiàn)在Web服務(wù)技術(shù)正日趨成熟护赊，所以有些應(yīng)用程序就有可能利用 Swing特性豐富的前端瘦客戶端結(jié)合Web或ejb層已經(jīng)開發(fā)出來的數(shù)據(jù)驗證和業(yè)務(wù)邏輯。此類應(yīng)用程序只有在受到保護的情況下才能正常運行砾跃，不過骏啰，安全性不一定意味著昂貴的成本。本文的目的就是要演示W(wǎng)eb服務(wù)客戶端如何通過安全的HTTPS協(xié)議使用自簽名的安全證書抽高。
HTTPS
通撑懈可以無縫地與不安全的HTTP協(xié)議一起使用，而不中斷用戶的體驗翘骂。這是由于SSL被設(shè)計為由可信的第三方進行驗證和簽名壁熄。Verisign是一家流行的認證機構(gòu)。如果您的Web應(yīng)用程序要求安全的通信碳竟，那么您就可以付錢給Verisign來簽名您的SSL證書草丧。經(jīng)過Verisign簽名之后，您的
Web站點上的用戶就可以不中斷地在HTTP與HTTPS之間進行切換莹桅，因為所有主流Web瀏覽器都信任由Verisign簽名的證書昌执。但是
Verisign并不是獲得簽名證書的惟一選擇。為了節(jié)省運作成本，或者為了個人使用方便懂拾，您也可以自簽名自己的證書煤禽。但是，自簽名證書會中斷Web站點用戶的體驗岖赋。通常Web瀏覽器會顯示一個對話框呜师，詢問您是否希望信任一個自簽名證書。
Web瀏覽器的這一特性很好贾节，因為當(dāng)其獲得一個由未知認證機構(gòu)簽名的證書時汁汗，還有機會進行處理。在開發(fā)用于通過HTTPS進行通信的Web服務(wù)客戶端時栗涂，這就沒那么容易了知牌。在運行Java代碼時，不會出現(xiàn)詢問是否信任一個不可信的認證機構(gòu)的對話框斤程。JRE會拋出一個異常角寸，說明試圖通過HTTPS連接到一個具有不可信證書的Web站點：
Caused by:sun.security.validator.ValidatorException:No trusted certificate found
無法捕獲此異常并繼續(xù)。要讓W(xué)eb服務(wù)使用自簽名證書忿墅，JRE必須以某種方式將您當(dāng)作認證機構(gòu)信任扁藕。
為演示此問題的解決方案，我將執(zhí)行以下步驟：
生成并自簽名我自己的證書疚脐；
為Tomcat配置SSL亿柑，使其使用該證書；
創(chuàng)建一個示例Web服務(wù)棍弄，以便通過HTTPS調(diào)用望薄；
從WSDL生成Web服務(wù)客戶端代碼；
使用定制的密鑰庫解決方案演示客戶端呼畸；
JDK附帶了一個工具痕支，keytool.exe，用于管理SSL公鑰/私鑰蛮原。密鑰在文件系統(tǒng)的一個二進制文件中進行添加和刪除卧须。默認的密鑰庫文件是
JAVA_HOME\jre\lib\security\cacerts。該文件包含了JRE所信任的認證機構(gòu)的列表儒陨。一個知名可信公司（比如
Verisign）的列表已經(jīng)存在于密鑰庫中了花嘶。要查看該列表，可使用口令changeit執(zhí)行以下代碼：
D:\>keytool -list -rfc -keystore JAVA_HOME\jre\lib\security\cacerts
Keytool應(yīng)用程序可用于編輯此文件框全。但是察绷，為了防止出錯，最好還是創(chuàng)建一個新文件津辩。如果不告知keytool使用哪個文件拆撼，它就會默認地創(chuàng)建HOME/.keystore容劳。
要生成自己的自簽名證書，可執(zhí)行：
D:\>keytool.exe -genkey -alias Tomcat -keyalg RSA -storepass bigsecret -keypass bigsecret -dname "cn=localhost"
執(zhí)行完該命令后闸度，就會在HOME目錄下生成一個.keystore文件竭贩。下面是各種切換命令的含義：
genkey：告訴keytool應(yīng)用程序生成新的公鑰/私鑰對。
alias：用于引用密鑰的名稱莺禁。記住留量，.keystore文件可包含多個密鑰。
Keyalg：使用RSA算法生成公鑰/私鑰對哟冬。
Storepass：訪問.keystore文件所需的口令楼熄。
Keypass：管理密鑰所需的口令。
dname：該值非常重要浩峡。.我使用了localhost可岂，因為該示例被設(shè)計為本地運行。如果一個Web應(yīng)用程序被注冊為http://www.myserver.com翰灾，那么該值就必須是www.myserver.com缕粹。如果名稱不匹配，證書就會自動被拒絕纸淮。
一旦keytool應(yīng)用程序創(chuàng)建了一個新的公鑰/私鑰對平斩，它就自動自簽名該密鑰。我們剛剛生成了自己的自簽名證書咽块，它可用于HTTPS通信绘面。只需提取出自簽名公鑰。后面我將展示如何做糜芳。
現(xiàn)在必須配置Tomcat飒货，使其使用自簽名證書。我使用的是Tomcat
5.0.30峭竣。編輯TOMCAT/conf/server.xml文件。在文件中搜索“8443”晃虫，并取消綁定到該端口的注釋皆撩。然后必須向添加下屬屬性：
keystorePass="bigsecret"
當(dāng)JRE啟動時，它將自動找到HOME/.keystore文件哲银，并且Tomcat會試著使用口令“bigsecret”訪問它扛吞。在Tomcat啟動時，控制臺應(yīng)該有如下輸出：
Feb 4, 2006 3:11:23 PM org.apache.coyote.http11.Http11Protocol start
INFO:Starting Coyote HTTP/1.1 on http-8443
這意味著成功地讀取了.keystore文件荆责，現(xiàn)在可以通過8443端口進行安全的HTTPS連接了滥比。打開Web瀏覽器，并在地址欄輸入https://localhost:8443/做院。因為該證書是自簽名的盲泛，所以Web瀏覽器將顯示一個對話框濒持，詢問是否信任該連接。如果接受寺滚，則所有的通信都將通過HTTPS進行柑营，從而成為安全的。
我將使用Apache Axis項目創(chuàng)建一個非常簡單的Web服務(wù)村视。該Web服務(wù)將模擬檢查新的電子郵件消息官套。Web服務(wù)客戶端傳遞一個惟一地識別一個用戶的令牌。Web服務(wù)返回一個新電子郵件消息的列表（參見清單1）蚁孔。
import java.util.*;
public class Email {
public List
getNewMessages(String id)
{
List l = new ArrayList(3);
l.add("1");
l.add("2");
l.add("3");
return l;
}
}
要獲取已部署的Web服務(wù)奶赔，執(zhí)行以下步驟：
從清單1剪切并粘貼代碼到Webapp的根目錄下的Email.jws文件。
編輯Web.xml文件杠氢，添加Axis servlet以及一個*.jws映射（清單2）纺阔。
將Axis jar文件放入WEB-INF/lib。請參見文章末尾的“參考資料”部分修然，獲取Axis項目URL笛钝。
AxisServlet
Apache-Axis Servlet
org.apache.axis.transport.http.AxisServlet
AxisServlet
*.jws
在部署了本文所附帶的WAR文件（并為Tomcat配置SSL）之后，Web就可以安全地通過HTTPS使用下面的URL來訪問了：
https://localhost:8443/JDJArticleWebService/Email.jws
Axis項目提供了一個名為WSDL2Java的工具愕宋，它獲取一個Web服務(wù)WSDL并自動創(chuàng)建使用該Web服務(wù)所需的Java源代碼玻靡。參見清單3中用于生成Email.jws Web服務(wù)代碼的命令行。
java
-classpath
.;axis.jar;log4j-1.2.8.jar
;commons-logging-1.0.4.jar
;commons-discovery-0.2.jar
;jaxrpc.jar;saaj.jar
;wsdl4j-1.5.1.jar
org.apache.axis.wsdl.WSDL2Java
-p jdj.wsclient.shared
http://localhost:8080/JDJArticle/Email.jws?wsdl
注意清單3
中用于訪問WSDL的URL中贝。它在8080端口使用了不安全的HTTP協(xié)議囤捻。為什么不在8443端口使用HTTPS呢？這是因為自簽名證書邻寿，WSDL2Java工具將遇到與本文所試圖解決的證書問題完全相同的問題蝎土。所以現(xiàn)在必須使用使用不安全的協(xié)議。這意味著生成的代碼必須有一點改變绣否，使用“https”和“8443”替換“http”和“8080”引用誊涯。本文所附帶的客戶端zip文件包含了更改后的代碼。
JRE的默認密鑰庫是JAVA_HOME\jre\lib\security\cacerts蒜撮。只要出現(xiàn)自簽名證書暴构，Java應(yīng)用程序就會拋出異常，因為該證書不在密鑰庫中段磨。因此取逾，在開發(fā)客戶端時有兩種選擇。第一種選擇是將自簽名證書放入該JRE的默認密鑰庫中苹支。雖然這種方法有效砾隅，但是它并不是一個好的解決方案，因為需要在每個客戶端機器上進行定制化债蜜。第二種選擇是生成一個定制的密鑰庫晴埂，將自簽名證書放入其中究反，并將定制密鑰庫作為應(yīng)用程序的一部分分發(fā)（通常在一個
jar文件中）。
要為客戶端創(chuàng)建定制密鑰庫邑时，需要執(zhí)行以下步驟：
從HOME/.keystore導(dǎo)出自簽名公鑰奴紧。
將自簽名公鑰導(dǎo)入到為客戶端創(chuàng)建的新密鑰庫中。
要從HOME/.keystore導(dǎo)出自簽名公鑰晶丘，可執(zhí)行以下代碼：
D:\>keytool.exe -genkey -alias Tomcat -keyalg RSA -storepass bigsecret -keypass bigsecret -dname "cn=localhost"
現(xiàn)在通過導(dǎo)入Tomcat.cer黍氮，為客戶端創(chuàng)建定制密鑰庫：
D:>keytool.exe -import -noprompt
-trustcacerts -alias Tomcat -file Tomcat.cer -keystore CustomKeystore
-storepass littlesecret
使用 “-keystore
CustomKeystore”，將會在當(dāng)前工作目錄中創(chuàng)建一個名為CustomKeystore的新密鑰庫文件浅浮∧可以在本文的客戶端zip文件的
/classpath/resources/keystore目錄下找到CustomKeystore文件。使用剛剛生成的文件替換該文件滚秩。
現(xiàn)在只剩下創(chuàng)建一個使用該定制密鑰庫的客戶端了专执。.我將演示兩種實現(xiàn)方法。
第一種方法是使用Java系統(tǒng)屬性javax.net.ssl.trustStore和javax.net.ssl.trustStorePassword來指向
CustomKeystore文件郁油，并提供訪問該文件的口令本股。jdj.wsclient.truststore包中的示例Web服務(wù)客戶端使用的就是這種方法（參見清單4）。
public static
void main(String[] args)
throws Exception
{
System.setProperty(
"javax.net.ssl.trustStore",
"classpath/resources/keystore/CustomKeystore");
System.setProperty(
"javax.net.ssl.trustStorePassword",
"littlesecret");
EmailServiceLocator wsl =
new EmailServiceLocator();
Email_PortType ews =
wsl.getEmail();
Object [] objects =
ews.getNewMessages("12345");
out("Msg Count: " + objects.length);
}
main()方法設(shè)置系統(tǒng)屬性桐腌，然后創(chuàng)建使用該Web服務(wù)的對象拄显。當(dāng)JRE需要訪問密鑰庫時，它就在文件系統(tǒng)中尋找
classpath/resources/keystore/CustomKeystore文件案站。雖然這只是一個簡單的解決方案躬审，但它還是存在問題，因為密鑰庫文件必須放在文件系統(tǒng)中蟆盐，而客戶端代碼也必須知道在哪里找到它承边。
第二種解決方案具有更好的可移植性，它將資源放在jar文件中石挂，從而避免了文件系統(tǒng)問題博助。客戶端代碼負責(zé)讀取CustomKeystore文件誊稚，并以某種方式使用它創(chuàng)建到服務(wù)器的安全連接翔始。jdj.wsclient.socketfactory包中的示例Web服務(wù)客戶端使用的就是這種方法（參見清單5）。
public MySocketFactory(Hashtable table)
throws Exception
{
out("Created!");
KeyStore ks =
KeyStore.getInstance(
KeyStore.getDefaultType()
);
char [] password =
"littlesecret".toCharArray();
String keystore =
"/resources/keystore/CustomKeystore";
Class tclass =
this.getClass();
InputStream is =
tclass.getResourceAsStream(
keystore
);
ks.load(is, password);
KeyManagerFactory kmf =
KeyManagerFactory.getInstance("SunX509");
kmf.init(ks,password);
TrustManagerFactory tmf =
TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);
SSLContext context =
SSLContext.getInstance("SSL");
context.init(
kmf.getKeyManagers(),
tmf.getTrustManagers(),
new SecureRandom()
);
factory =
context.getSocketFactory();
}
清單5顯示了如何將CustomKeystore文件作為資源讀取里伯，并使用它來創(chuàng)建javax.net.ssl.SSLSocketFactory。配置Axis可插入架構(gòu)渤闷，然后可使用MySocketFactory類從該工廠創(chuàng)建安全的Socket對象疾瓮。
本文以一個簡單的問題開始：我希望使用自簽名的證書保護通過HTTPS的Web服務(wù)通信。默認情況下飒箭，JRE會拒絕應(yīng)用程序的自簽名證書狼电，因為它不是來自于可信的認證機構(gòu)蜒灰。要讓安全的通信可運行，必須讓W(xué)eb服務(wù)客戶端JRE信任自簽名證書肩碟。為此强窖，我使用keytool應(yīng)用程序生成一個新的公鑰/私鑰對，提取出自簽名公鑰削祈，然后創(chuàng)建一個新的密鑰庫翅溺，并導(dǎo)入該自簽名證書。然后我創(chuàng)建一個不需要任何客戶端配置的髓抑、完全自包含的Web服務(wù)客戶端
