本文提出了 IBM? JSSE（Java? Secure Socket Extension
Java? 安全套接字擴展）的配置問題
探討了密鑰庫和信任庫
並且對於如何在 IBM WebSphere? Application Server 環境下處理這些重要的 JSSE 元素提出了的建議
引言 Java 安全套接字擴展（Java Secure Socket Extension
JSSE）是將低級編程接口封裝到安全套接字層（Secure Socket Layer
SSL）協議及其相應的標准傳輸層安全性（Transport Layer Security
TLS）協議中的 Java 標准
IBM JSSE 是 JSSE 框架的 Java 實現
它支持 SSL V
和 V
以及 TLS V
將 JSSE 這樣架構以便其能夠提供兩套接口
一套被稱為服務提供方接口（Service Provider Interface
SPI）
而另一套是應用程序編程接口（Application Programming Interface
API）
那些提供特定實現的功能插件使用提供的程序接口（本質上
是接口中的插件）
通常
應用程序開發人員僅處理 API
他們可以編寫可移植的代碼
該代碼僅依賴於標准的公共 API 中公布的方法
IBM JSSE 實現也包括 IBM JSSE 加密提供方
重要的是
開發人員應該遵循最佳的編程實踐來啟用應用程序的可移植性
只要沒有將提供應用程序的特定信息的用法嵌入或強制編碼到應用程序中
JSSE API 就可以進行移植
IBM 沒有聲明與其它 JSSE 提供方的互操作性
IBM 開發實驗室沒有執行任何正式的測試
分離 API 和 SPI 接口的目的在於保護來源於程序提供者的應用程序
以便達到可移植性
但每個程序提供者所提供的功能可能不必與其它提供的功能相匹配
IBM JSSE 包括了 IBM 的提供方
而其他供應商擁有自己的提供方
當使用 WebSphere Application Server 時
例如
我們重在 IBM 自己的提供方
因此
應用程序代碼假設任何特殊的提供方都是不可移植的
一個公共實例是顯式地裝載了 com
sun
* 類的應用程序代碼
由於 com
sun
* 不是 JSSE（或者對於那種情況是 J
SE）的一部分
所以這樣的代碼是不可移植的
當您開發您的代碼時
應該盡量避免程序提供者所特有的依賴
我們此處的實例說明了這種方法
簡化 JSSE 編程很大程度上是由於高級別的抽象
它提供了關於標准套接字的編程接口
這使得在兩個希望使用 TCP/IP 協議上的傳輸層安全性來進行消息傳遞的終端之間建立網絡連接變得非常容易
由 JSSE 提供的安全性服務是由傳輸層消息完整性
可靠性（加密）
服務器驗證
以及可選的客戶端驗證組成
在本文中
我們提出了 IBM JSSE 的配置問題
探討了密鑰庫和信任庫
並且推薦了在 WebSphere Application Server 環境下處理這些重要的 JSSE 元素的方法
隨後
我們給出了 JSSE 編程模型並且說明當訪問 HTTPS 上的可用資源時它是多麼簡單
最後
我們說明了怎樣在單一應用程序中同時使用多重密鑰庫/信任庫
SSL 是由 Netscape Communications Corporation 於
年開發的
而 TLS V
是由 Internet Engineering Task Force（IETF）定義的標准
它基於 SSL V
並且在使用的加密算法上與其有些許的不同
例如
SSL 使用 Message Authentication Code（MAC）算法來生成完整性校驗值
而 TLS 應用密鑰的 Hashing for Message Authentication Code（HMAC）算法
配置及安裝 IBM JSSE我需要做什麼嗎？ WebSphere Application Server V
（以及後續的）和 WebSphere Studio V
一起傳輸 ibmjsse
jar（支持 JSSE
版本）及其相關的 certpath
jar
因此
IBM JSSE 由運行在 WebSphere Application Server 環境下的應用程序自動地使用
重申
WebSphere Application Server 包括了 JSSE 並完全地未經優化的支持它
您的部分中無需進一步的安裝
事實上
禁止替換其他來源的 JSSE 或 JCE 實現
（您不能忽略核心的運行函數
當然
您可以擁有額外的提供方
但不能替換那裡已存在的提供方）
您必須確保 JSSE 及其支持的 JAR 文件
例如 certpath
jar
在開發過程中位於您的類路徑上（在運行時它們常常位於類路徑上）
certpath
jar 是一個包
包含證書路徑結構及 JSSE 運行時需要的驗證功能
以便建立證書信任路徑
您無需對 certpath
jar API 編程來建立 SSL/TLS 通信通道
但 JSSE 將會使用它
IBM JSSE 提供了 JSSE 功能用於您的 WebSphere Application Server 環境以及部署過的應用程序
這是靜態地設置在 java
security 配置文件中的
該文件位於您的 WAS 安裝路徑下的 JDK 目錄中
下面是 Windows? 系統的 java
security 文件中未經優化的缺省提供方的清單
注意
不同平台之間的提供方的名稱是一樣的
然而
排序可能是不同的
無論何種平台
您的用於 WebSphere Application Sever 的未經優化的 JSSE 提供方都是 IBMJSSEProvider
#
# List of providers and their preference orders
#
security
provider
=sun
security
provider
Sun
security
provider
=com
ibm
crypto
provider
IBMJCE
security
provider
=com
ibm
jsse
IBMJSSEProvider
security
provider
=com
ibm
security
cert
IBMCertPath
security
provider
=com
ibm
crypto
pkcs
provider
IBMPKCS
您無需更改其中的任一個
如果您很好奇
那麼此處存在大量的提供方
大多數都與 JSSE 無關
與 JSSE 相關的提供方只是 IBMJSSEProvider
IBMJCE 以及 IBMCertPath
後兩者由 IBMJSSEProvider 隱含地使用來進行證書處理及加密操作
信任庫和密鑰庫它們是什麼以及我為何關注它們？ SSL 協議基於公鑰密碼
加密密鑰成對地出現在公鑰密碼中
它們是在數學上是相關的
但無法由一個推知另一個
這對加密密鑰由私有密鑰和公有密鑰（私有
公共）組成的
私有密鑰一直處於其所屬實體的保護之下
注意
所有者確實擁有這對加密密鑰
但公共密鑰
如同它的名稱所示
可以為眾所周知
或至少自由地分散到與公共/私有密鑰對通信的實體中
公鑰密碼啟用的安全性服務是基於這樣的消息解密機制
即共有密鑰只能通過相應的私有密鑰才能解密
反之亦然
這樣
如果使用實體的公鑰加密消息
那麼可以保證只有該實體能夠解密此消息
這時會在腦海中立即出現一個問題
即怎樣確保正在使用的公鑰的確被綁定到合法實體上而沒有綁定到其它實體上
在此 Public Key Infrastructures（PKI）開始起作用了（請見參考資料）
圖 客戶端和服務器信任庫/密鑰庫間的關系
公有密鑰分布於名為公鑰證書（PKC）的容器中
這些是由某一簽名者（通常是 Certificate Authority
但公鑰可以是自簽名的）數字化地簽署的
數字簽名標志原始的真實性的驗證
要記住的一點是相信計算機安全一定能通過計算的方法驗證
為了驗證公鑰證書是合法的
我需要檢驗發出該簽名的簽名者
相反
這個過程是基於簽名者的公有密鑰的
在這裡使用信任庫
當將 JSSE 用於 SSL 通信時
需要在本地存儲中維護一套信任的簽名者的證書
由此得名信任庫
例如
由 JSSE 運行時使用的客戶端信任庫為了驗證試圖連接到服務器的客戶端確實使用合法的證書（由信任的簽名者發出的）與服務器交互
因此
服務器證書的簽名者必須持有保存在客戶端信任庫中的 PKC
圖
闡明了客戶端和服務器信任庫/密鑰庫間的關系
出於同樣的機制
服務器必須本地保護它的私有密鑰並且使其能夠訪問 JSSE 運行時
在此處使用密鑰庫
密鑰庫與信任庫有相同的格式
它只包含了不同的密鑰
實際上
專業術語
密鑰庫
通常表示
信任庫或密鑰庫
總之
信任庫包含了簽名者的證書
該簽名者在使用信任庫的環境中得到信任
另一方面
密鑰庫維護了實體的私有密鑰
及其相應的 PKC
例如
當服務器面向客戶端進行自身驗證時
它需要從其密鑰庫中檢索它的私有密鑰來與加入客戶端的 SSL 握手
所以
應該確實地重視信任什麼簽名者
也就是說
使用信任庫的哪些內容
IBM 提供的缺省信任庫包括了一些公認的且廣泛信任的 Certificate Authorites（CA）
在這裡一種好的實踐是周期性地浏覽您的信任庫並且作出您關於其內容可信性的判斷——可能刪除一些 CA
現在我們已經知道信任庫是什麼以及密鑰庫是什麼
讓我們來了解一下使用 IBM JSSE 在 WebSphere Application Server 環境中是如何定義它們的
如何指定密鑰庫和信任庫 為了打開 JSSE 的連接
您必須在信任庫和密鑰庫中擁有合適的證書以及私有密鑰
您需要配置 JVM 來使用您的信任庫或密鑰庫
然而
如果您僅執行服務器驗證（就是說
客戶端使服務器的證書生效
但不允許反向）
那麼您只需要信任庫
如果您在沒有明確地指定信任庫或密鑰庫的情況下創建 SSL 連接
那麼 JSSE 運行時將會使用
缺省
庫
對於 WebSphere Application Server 來說
意味著 cacerts 文件被用作缺省的信任庫（位於 WAS 安裝目錄下的 java/jre/lib/security 中）
如果您聯系的站點使用由公認的 CA 發出的證書
那麼 IBM 提供的缺省證書很可能已經包含了您需要的信息
您可以使用 IBM 提供的 iKeyman 工具（WebSphere Application Server 安裝後自動可用）打開 cacerts 文件來確定 JDK 中包含什麼證書
如果您訪問的站點沒有使用由 CA 發出的證書
CA 被包含在 WebSphere Application Server 中
那麼您需要獲得它們的簽名證書並且將其添加到信任庫中
我們推薦您不要修改現有的 JDK 文件
而是使用 iKeyman 創建新的信任庫
然後您需要配置 WebSphere Application Server 運行時來使用該信用庫
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27642.html
