幾個月以前，我遇到一個客戶站點，他們剛剛將其服務器從8.1sp1升級到8.1sp4。很明顯，升級過程很成功，在測試時也沒遇到大的問題。他們的問題是：升級成功後，他們的許多證書都快要到期了。我們很快意識到更新密鑰庫將是一項浩大的工程，有3個原因：首先，需要更新的證書和密鑰庫的數量龐大；其次，構建以及整理過程使得在向相應的密鑰庫中添加新證書時會產生很大的混亂；最後，獲得證書簽名的過程令人非常痛苦。
在這項龐大工程完成之後不久，出現了問題的第一個征兆。在峰值負載下，我們發現負載均衡功能不起作用了。集群中的一些服務器在做所有的工作，而其它的服務器則幾乎完全是不活動的。我們最初的分析成效不大，所以我們決定使用微軟的標准故障排除模式，當天晚上重啟所有的WLS和apache服務器。
接下來的幾天很平靜，似乎一切都沒問題了。我們認為這個問題只是集群中的偶然故障，因為日志中沒有什麼記錄，在測試環境中也沒有發生該問題，所以我們就結束了這個個案。當天晚上由於應用程序中的一些線程需要重啟兩個活動的服務器。重啟的兩個服務器並沒有出現問題的跡象，但是第二天就出現了上述問題的大范圍爆發，而且不僅是在活動的環境中，後來幾乎所有最近重啟過的其它環境都報告了這一問題。這一次，日志中有了錯誤記錄：
####
<>
A decryption error occurred during the SSL handshake.>
我們主要關心的是如何減輕活動服務器上的問題。我們猜測重啟集群而不是重啟單個的服務器就不會出現解密錯誤，事實證明確實如此。但是，我們發現，如果有服務器脫離了集群（這可能是由很多原因造成的），那麼當該服務器試圖重新連入集群中時就會出現解密錯誤。這些“流浪”的服務器會對集群造成很大損害，因為一個或多個Apache服務器可能會認為它仍然是集群中的一部分，並向該服務器發送請求，然後就會被該服務器告知：它是集群中唯一的服務器。在apache插件配置中啟動調試後，就可以檢測到該行為。我們必須監視weblogic serverlog的BEA-000112和BEA-000113消息，並關閉任何脫離集群的服務器。
將問題控制在活動服務器上之後，我們試著找出根本原因。主要的疑點集中在密鑰庫和新證書上。看起來，在使用新證書更新密鑰庫之後遇到SSL問題並非只是巧合。也許在此過程中我們以某種方式損壞了密鑰庫。我們使用keytool檢查了所有的密鑰庫、密鑰和證書，但是一無所獲。
問題持續了六周，我們不辭辛苦地審計所有環境，檢查冗長的日志文件。最終我們發現了問題的根源。在升級到WLS 8.1 sp4的過程中，SSL的TwoWaySSLEnabled屬性從“Client Certificate Not Requested”變為“Client Certificate Requested But Not Enforced”。這並不是我們更改的，我們還保留了一個被設置為“ClIEnt Certificates Not Requested”的8.1 sp1平台，它沒有出現任何升級後的環境所發生的症狀。config.XML文檔說該屬性的值只能是true或false，而管理控制台似乎提供了第三種選項：請求並可能實施一個客戶端證書！
想知道如果刪除了WLS域目錄再運行域會出現什麼情況嗎？在我的下一篇文章“Ghost in the Korn Shell”中，我將介紹在發生了這樣的不幸事件之後如何部屬域。
