HTTPS 簡介 ...........................................................................................

HTTPS 簡介 ............................................................................................................................. 1

HTTPS 解決的問題與限制 ..................................................................................................... 2

IE 瀏覽器如何驗證SSL 證書 ............................................................................................... 3

SSL 介紹 ................................................................................................................................. 4

SSL 協(xié)議的握手過程 ............................................................................................................. 5

證書各部分的含義 ................................................................................................................ 5

加密技術(shù)簡介 ........................................................................................................................ 7

幾個驗證小例子 .................................................................................................................... 8 J AVA 操作SSL SOCKET ..................................................... 8

keytool 證書與密鑰管理 . ..................................................................................................... 8

Java sslSocket 聊天實例 . .................................................................................................. 9 用COMMVIEW 工具截獲瀏覽器訪問支付寶的TCP/IP包 ........................ 14 J AVA SSL SOCKET 操作HTTP 訪問支付寶（HTTPS ） ............................ 18 J AVA SSL SOCKET 雙向認證 ............................................... 19

建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；確認網(wǎng)站的真實性即認證 https 簡介

它是由Netscape 開發(fā)并內(nèi)置于其瀏覽器中，用于對數(shù)據(jù)進行壓縮和解壓操作，并返回網(wǎng)絡(luò)上傳送回的結(jié)果。HTTPS 實際上應(yīng)用了Netscape 的安全套接字層（SSL ）作為HTTP 應(yīng)用層的子層。（HTTPS 使用端口443，而不是象HTTP 那樣使用端口80來和TCP/IP進行通信。）SSL 使用40 位關(guān)鍵字作為RC4流加密算法，這對于商業(yè)信息的加密是合適的。HTTPS 和SSL 支持使用X.509數(shù)字認證，如果需要的話用戶可以確認發(fā)送者是誰。

也就是說它的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認網(wǎng)站的真實性。

HTTPS 和HTTP 的區(qū)別

一、https 協(xié)議需要到ca 申請證書，一般免費證書很少，需要交費。

二、http 是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl 加密傳輸協(xié)議。

三、http 和https 使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

四、http 的連接很簡單，是無狀態(tài)的；HTTPS 協(xié)議是由SSL HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，比http 協(xié)議安全。

它的安全保護依賴瀏覽器的正確實現(xiàn)以及服務(wù)器軟件、實際加密算法的支持. 一種常見的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊。”實際上，與服務(wù)器的加密連接中能保護銀行卡號的部分，只有用戶到服務(wù)器之間的連接及服務(wù)器自身。并不能絕對確保服務(wù)器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數(shù)罕見攻擊在網(wǎng)站傳輸客戶數(shù)據(jù)時發(fā)生，攻擊者會嘗試竊聽傳輸中的數(shù)據(jù)。

商業(yè)網(wǎng)站被人們期望迅速盡早引入新的特殊處理程序到金融網(wǎng)關(guān)，僅保留傳輸碼(transaction number)。不過他們常常存儲銀行卡號在同一個數(shù)據(jù)庫里。那些數(shù)據(jù)庫和服務(wù)器少數(shù)情況有可能被未授權(quán)用戶攻擊和損害。

TLS 1.1之前這段僅針對TLS 1.1之前的狀況。因為SSL 位于http 的下一層，并不能理解更高層協(xié)議，通常SSL 服務(wù)器僅能頒證給特定的IP/端口組合。這是指它經(jīng)常不能在虛擬主機(基于域名) 上與HTTP 正常組合成HTTPS 。

這一點已被即將來臨的TLS 1.1更新為—種完全支持基于域名的虛擬主機。

HTTPS 解決的問題與限制

一、信任主機的問題.

采用https 的服務(wù)器必須從CA （Certificate Authority）申請一個用于證明服務(wù)器用途類型的證書。該證書只有用于對應(yīng)的服務(wù)器的時候，客戶端才信任此主機。所以目前所有的銀行系統(tǒng)網(wǎng)站，關(guān)鍵部分應(yīng)用都是https 的?？蛻敉ㄟ^信任該證書，從而信任了該主機。其實這樣做效率很低，但是銀行更側(cè)重安全。這一點對我們沒有任何意義，我們的服務(wù)器，采用的證書不管是自己發(fā)布的還是從公眾的地方發(fā)布的，其客戶端都是自己人，所以我們也就肯定信任該服務(wù)器。

IE 瀏覽器中已經(jīng)內(nèi)置了大量證書頒發(fā)機構(gòu)的公鑰，通過下面的操作我們可以查看到已經(jīng)被信任的證書頒發(fā)機構(gòu)。在IE 瀏覽器的菜單中點擊“工具/Internet選項”，選擇“內(nèi)容”標簽，點擊“證書”按鈕，然后就可以看到IE 瀏覽器已經(jīng)信任了許多“中級證書頒發(fā)機構(gòu)”和“受信任的根證書頒發(fā)機構(gòu)。當我們在訪問該網(wǎng)站時，瀏覽器就會自動下載該網(wǎng)站的SSL 證書，并對證書的安全性進行檢查。

由于證書是分等級的，網(wǎng)站擁有者可能從根證書頒發(fā)機構(gòu)領(lǐng)到證書，也可能從根證書的下一級（如某個國家的認證中心，或者是某個省發(fā)出的證書）領(lǐng)到證書。假設(shè)我們正在訪問某個使用了 SSL 技術(shù)的網(wǎng)站，IE 瀏覽器就會收到了一個SSL 證書，如果這個證書是由根證書頒發(fā)機構(gòu)簽發(fā)的，IE 瀏覽器就會按照下面的步驟來檢查：瀏覽器使用內(nèi)置的根證書中的公鑰來對收到的證書進行認證，如果一致，就表示該安全證書是由可信任的頒證機構(gòu)簽發(fā)的，這個網(wǎng)站就是安全可靠的；如果該SSL 證書不是根服務(wù)器簽發(fā)的，瀏覽器就會自動檢查上一級的發(fā)證機構(gòu)，直到找到相應(yīng)的根證書頒發(fā)機構(gòu)，如果該根證書頒發(fā)機構(gòu)是可信的，這個網(wǎng)站的SSL 證書也是可信的。

二、通訊過程中的數(shù)據(jù)的泄密和被篡改

1． 一般意義上的https ，就是服務(wù)器有一個證書。

a) 主要目的是保證服務(wù)器就是他聲稱的服務(wù)器，這個跟第一點一樣。 b) 服務(wù)端和客戶端之間的所有通訊，都是加密的。

i. 具體講，是客戶端產(chǎn)生一個對稱的密鑰，通過服務(wù)器的證書來交換密鑰，即一般意義上的握手過程。

ii. 接下來所有的信息往來就都是加密的。第三方即使截獲，也沒有任何意義，因為他沒有密鑰，當然篡改也就沒有什么意義了。

2． 少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。

a) 這里客戶端證書，其實就類似表示個人信息的時候，除了用戶名/密碼，還有一個CA 認證過的身份。因為個人證書一般來說是別人無法模擬的，所有這樣能夠更深的確認自己的身份。

b) 目前少數(shù)個人銀行的專業(yè)版是這種做法，具體證書可能是拿U 盤（即U 盾）作為一個備份的載體。

IE 瀏覽器如何驗證SSL 證書

IE 瀏覽器中已經(jīng)內(nèi)置了大量證書頒發(fā)機構(gòu)的公鑰，通過下面的操作我們可以查看到已經(jīng)被信任的證書頒發(fā)機構(gòu)。在IE 瀏覽器的菜單中點擊“工具/Internet選項”，選擇“內(nèi)容”標簽，點擊“證書”按鈕，然后就可以看到IE 瀏覽器已經(jīng)信任了許多“中級證書頒發(fā)機構(gòu)”和“受信任的根證書頒發(fā)機構(gòu)。當我們在訪問該網(wǎng)站時，瀏覽器就會自動下載該網(wǎng)站的SSL 證書，并對證書的安全性進行檢查。

由于證書是分等級的，網(wǎng)站擁有者可能從根證書頒發(fā)機構(gòu)領(lǐng)到證書，也可能從根證書的下一級（如某個國家的認證中心，或者是某個省發(fā)出的證書）領(lǐng)到證書。假設(shè)我們正在訪問某個使用了 SSL 技術(shù)的網(wǎng)站，IE 瀏覽器就會收到了一個SSL 證書，如果這個證書是由根證書頒發(fā)機構(gòu)簽發(fā)的，IE 瀏覽器就會按照下面的步驟來檢查：瀏覽器使用內(nèi)置的根證書中的公鑰來對收到的證書進行認證，如果一致，就表示該安全證書是由可信任的頒證機構(gòu)簽發(fā)的，這個網(wǎng)站就是安全可靠的；如果該SSL 證書不是根服務(wù)器簽發(fā)的，瀏覽器就會自動檢查上一級的發(fā)證機構(gòu)，直到找到相應(yīng)的根證書頒發(fā)機構(gòu)，如果該根證書頒發(fā)機構(gòu)是可信的，這個網(wǎng)站的SSL 證書也是可信的。

client 端接收到了server 的證書，怎樣和client 中的public key 來認證服務(wù)端呢？需要回答4個問題：

1.server 的證書過期了嗎？

2.server 證書中的issuing CA是trusted CA?

如果server 證書中的issuing CA的distinguished name和client 的trusted CA的某個證書的distinguished name相同，則答案是肯定的。

如果server 證書中的issuing CA沒有在trusted CA列表中，但the client can verify a certificate chain ending in a CA that is on the list，仍然可以。

3.client 的issuing CA的public key能否驗證server 證書中的issuer's digital

signature?

4. 在server 證書中的domain name和server 的domain name是不是相同的？

SSL 介紹

為Netscape 所研發(fā)，用以保障在Internet 上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會被截取及竊聽。目前一般通用之規(guī)格為40 bit之安全標準，美國則已推出128 bit之更高安全標準，但限制出境。只要3.0版本以上之I.E. 或Netscape 瀏覽器即可支持SSL 。

當前版本為3.0。它已被廣泛地用于Web 瀏覽器與服務(wù)器之間的身份認證和加密數(shù)據(jù)傳輸。

SSL 協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL 協(xié)議可分為兩層：SSL 記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP ）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。SSL 握手協(xié)議（SSL Handshake Protocol）：它建立在SSL 記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。

SSL 協(xié)議提供的服務(wù)主要有哪些？

1）認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器

2）加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取

3）維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。

SSL 協(xié)議的工作流程

服務(wù)器認證階段：1）客戶端向服務(wù)器發(fā)送一個開始信息“Hello ”以便開始一個新的會話連接；2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要則服務(wù)器在響應(yīng)客戶的“Hello ”信息時將包含生成主密鑰所需的信息；3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器；4）服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個用主密鑰認證的信息，以此讓客戶認證服務(wù)器。

用戶認證階段

在此之前，服務(wù)器已經(jīng)通過了客戶認證，這一階段主要完成對客戶的認證。經(jīng)認證的服務(wù)器發(fā)送一個提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務(wù)器提供認證。

從SSL 協(xié)議所提供的服務(wù)及其工作流程可以看出，SSL 協(xié)議運行的基礎(chǔ)是商家對消費者信息保密的承諾，這就有利于商家而不利于消費者。在電子商務(wù)初級階段，由于運作電子商務(wù)的企業(yè)大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務(wù)的發(fā)展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數(shù)字簽名和數(shù)字證書可實現(xiàn)瀏覽器和Web 服務(wù)器雙方的身份驗證，但是SSL 協(xié)議仍存在一些問題，比如，只能提供交易中客戶與服務(wù)器間的雙方認證，在涉及多方的電子交易中，SSL 協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關(guān)系。在這種情況下，Visa 和MasterCard 兩大信用卡公組織制定了SET 協(xié)議，為網(wǎng)上信用卡支付提供了全球性的標準。

SSL 協(xié)議的握手過程

①客戶端的瀏覽器向服務(wù)器傳送客戶端SSL 協(xié)議的版本號，加密算法的種類，產(chǎn)生的隨機數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。

②服務(wù)器向客戶端傳送SSL 協(xié)議的版本號，加密算法的種類，隨機數(shù)以及其他相關(guān)信息，同時服務(wù)器還將向客戶端傳送自己的證書。

③客戶利用服務(wù)器傳過來的信息驗證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續(xù)進行第四步。

④用戶端隨機產(chǎn)生一個用于后面通訊的“對稱密碼”，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書中獲得）對其加密，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。

⑤如果服務(wù)器要求客戶的身份認證（在握手過程中為可選），用戶可以建立一個隨機數(shù)然后對其進行數(shù)據(jù)簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。

⑥如果服務(wù)器要求客戶的身份認證，服務(wù)器必須檢驗客戶證書和簽名隨機數(shù)的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發(fā)行CA 的公鑰能否正確解開客戶證書的發(fā)行CA 的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL ）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務(wù)器將用自己的私鑰解開加密的“預(yù)主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。 ⑦服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個對稱密鑰用于SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時在SSL 通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

⑧客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知服務(wù)器客戶端的握手過程結(jié)束。

⑨服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知客戶端服務(wù)器端的握手過程結(jié)束。

⑩SSL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務(wù)器開始使用相同的對稱密鑰進行數(shù)據(jù)通訊，同時進行通訊完整性的檢驗。

證書各部分的含義

證書版本號，不同版本的證書格式不同

Serial Number 序列號，同一身份驗證機構(gòu)簽發(fā)的證書序列號唯一

Algorithm Identifier 簽名算法，包括必要的參數(shù)Issuer 身份驗證機構(gòu)的標識信息

Period of Validity 有效期

Subject 證書持有人的標識信息

Subject ’s Public Key 證書持有人的公鑰

Signature 身份驗證機構(gòu)對證書的簽名

證書的格式 認證中心所發(fā)放的證書均遵循X.509 V3 標準，其基本格式如下： 證書版本號（Certificate Format Version）

含義：用來指定證書格式采用的X.509 版本號。

證書序列號（Certificate Serial Number）

含義：用來指定證書的唯一序列號，以標識CA 發(fā)出的所有公鑰證書。 簽名（Signature ）算法標識（Algorithm Identifier）

含義：用來指定 CA 簽發(fā)證書所用的簽名算法。

簽發(fā)此證書的 CA 名稱（Issuer ）

含義：用來指定簽發(fā)證書的 CA 的X.500 唯一名稱（DN ，Distinguished Name）。 證書有效期（Validity Period）起始日期（notBefore ） 終止日期（notAfter ） 含義：用來指定證書起始日期和終止日期。

用戶名稱（Subject ）

含義：用來指定證書用戶的X.500 唯一名稱（DN ，Distinguished Name）。 用戶公鑰信息（Subject Public Key Information）算法（algorithm ） 算法標識（Algorithm Identifier ）用戶公鑰（subject Public Key ）

含義：用來標識公鑰使用的算法，并包含公鑰本身。

證書擴充部分（擴展域）（Extensions ）

含義：用來指定額外信息。

X.509 V3 證書的擴充部分（擴展域）及實現(xiàn)方法如下：

CA 的公鑰標識（Authority Key Identifier ）

公鑰標識（SET 未使用）（Key Identifier ）

簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificate Issuer ）

簽發(fā)證書者證書的序列號（Certificate Serial Number）

X.509 V3 證書的擴充部分（擴展域）及實現(xiàn)CA 的公鑰標識（Authority Key Identifier ）

公鑰標識（SET 未使用）（Key Identifier ）

簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificat 簽發(fā)證書者證書的序列號（Certificate Serial Number）

含義：CA 簽名證書所用的密鑰對的唯一標識用戶的公鑰標識（Subject Key Identifier ）

含義：用來標識與證書中公鑰相關(guān)的特定密鑰進行解密。

證書中的公鑰用途（Key Usage ）

含義：用來指定公鑰用途。

用戶的私鑰有效期（Private Key Usage Period ）起始日期（Note Before ） 終止日期（Note After ）

含義：用來指定用戶簽名私鑰的起始日期和終止日期。

CA 承認的證書政策列表（Certificate Policies）

含義：用來指定用戶證書所適用的政策，證書政策可由對象標識符表示。 用戶的代用名（Substitutional Name ）

含義：用來指定用戶的代用名。

CA 的代用名（Issuer Alt Name ）

含義：用來指定 CA 的代用名。

基本制約（Basic Constraints ）

含義：用來表明證書用戶是最終用戶還是CA 。 在SET 系統(tǒng)中有一些私有擴充部分（擴展域）Hashed Root Key 含義：只在根證書中使用，用于證書更新時進行回溯。

證書類型（Certificate Type ）

含義：用來區(qū)別不同的實體。該項是必選的。

商戶數(shù)據(jù)（Merchant Data ）

含義：包含支付網(wǎng)關(guān)需要的所有商戶信息。

持卡人證書需求（Card Cert Required ）

含義：顯示支付網(wǎng)關(guān)是否支持與沒有證書的持卡人進行交易。

SET 擴展（SETExtensions ）

含義：列出支付網(wǎng)關(guān)支持的支付命令的 SET 信息擴展。

CRL 數(shù)據(jù)定義版本（Version ）

含義：顯示 CRL 的版本號。

CRL 的簽發(fā)者（Issuer ）

含義：指明簽發(fā) CRL 的CA 的甄別名。

CRL 發(fā)布時間（this Update ）預(yù)計下一個 CRL 更新時間（Next Update ）撤銷證書信息目錄（Revoked Certificates ） CRL 擴展（CRL Extension ）CA 的公鑰標識（Authority Key Identifier ）CRL 號（CRL Number ）

加密技術(shù)簡介

加密技術(shù)包括兩個元素：算法和密鑰。算法是將普通的文本（或者可以理解的信息）與一串數(shù)字（密鑰）的結(jié)合，產(chǎn)生不可理解的密文的步驟，密鑰是用來對數(shù)據(jù)進行編碼和解碼的一種算法。在安全保密中，可通過適當?shù)拿荑€加密技術(shù)和管理機制來保證網(wǎng)絡(luò)的信息通訊安全。密鑰加密技術(shù)的密碼體制分為對稱密鑰體制和非對稱密鑰體制兩種。相應(yīng)地，對數(shù)據(jù)加密的技術(shù)分為兩類，即對稱加密（私人密鑰加密）和非對稱加密（公開密鑰加密）。對稱加密以數(shù)據(jù)加密標準（DES ，Data Encryption Standard）算法為典型代表，非對稱加密通常以RSA （Rivest Shamir

Ad1eman ）算法為代表。對稱加密的加密密鑰和解密密鑰相同，而非對稱加密的加密密鑰和解密密鑰不同，加密密鑰可以公開而解密密鑰需要保密。

對稱加密采用了對稱密碼編碼技術(shù)，它的特點是文件加密和解密使用相同的密鑰，即加密密鑰也可以用作解密密鑰，這種方法在密碼學(xué)中叫做對稱加密算法，對稱加密算法使用起來簡單快捷，密鑰較短，且破譯困難，除了數(shù)據(jù)加密標準

（DES ），另一個對稱密鑰加密系統(tǒng)是國際數(shù)據(jù)加密算法（IDEA ），它比DES 的加

密性好，而且對計算機功能要求也沒有那么高。IDEA 加密標準由PGP （Pretty Good Privacy）系統(tǒng)使用。

1976年，美國學(xué)者Dime 和Henman 為解決信息公開傳送和密鑰管理問題，提出一種新的密鑰交換協(xié)議，允許在不安全的媒體上的通訊雙方交換信息，安全地達成一致的密鑰，這就是“公開密鑰系統(tǒng)”。相對于“對稱加密算法”這種方法也叫做“非對稱加密算法”。與對稱加密算法不同，非對稱加密算法需要兩個密鑰：公開密鑰（publickey ）和私有密 （privatekey ）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數(shù)據(jù)進行加密，只有用對應(yīng)的私有密鑰才能解密；如果用私有密鑰對數(shù)據(jù)進行加密，那么只有用對應(yīng)的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。

幾個驗證小例子

Java 操作ssl socket

keytool 證書與密鑰管理

1) 創(chuàng)建服務(wù)端密鑰庫

>keytool -genkey -keystore c:serverkey.jks -keyalg rsa -alias ssl1 -validity 700 上述命令中:

-genkey 生成密鑰對

-keystore 指定密碼倉庫的文件地址

-keyalg 密鑰所使用的算法

-alias 密鑰別名.. 使用密鑰時是使用此別名來區(qū)分的

-validity 密鑰有效期(天).. 從當前系統(tǒng)時間開始計算

該命令成功后會要求輸入密碼倉庫的密碼.. 例如changeit

然后是輸入你的個人信息..

最后會要求輸入別名的密碼.. 例如changeit

創(chuàng)建成功后.. 在建立服務(wù)端的SSL 連接時用下述方法導(dǎo)入密鑰..

String keyFile = serverkey.jks

String keyFilePass = "changeit"

KeyStore ks = KeyStore.getInstance("JKS");

ks.load(new FileInputStream(keyFile), keyFilePass.toCharArray());

再利用該密碼倉庫來進行相應(yīng)操作..

2) 將服務(wù)端的公鑰導(dǎo)出成證書

>keytool -export -alias ssl1 -file c:ssl1.cer -keystore c:serverkey.jks

-export 導(dǎo)出

導(dǎo)出成功后就得到了ssl1.cer 這一份證書了.. 然后就是要將這一份證書分發(fā)給客戶端.. 客戶端有了該證書后就能與服務(wù)端建立安全連接了..

3) 生成客戶端的密鑰倉庫

方法與1) 類似

keytool -genkey -keystore c:clientkey.jks -keyalg rsa -alias ssl1 -validity 700

4) 將*.cer導(dǎo)入到客戶端的密鑰倉庫里

>keytool -import -file c:ssl1.cer -keystore c:clientkey.jks

-import 導(dǎo)入

上述命令成功后會要求輸入客戶端密鑰倉庫的密碼..

成功后在每次要訪問服務(wù)端之前還要將該證書添加到受信域中.. 系統(tǒng)會自動從受信域中檢查可用的證書來完成SSL 連接通訊..

String keyFile = clientkey.jks

String keyFilePass = "changeit"

System.setProperty("javax.net.ssl.trustStore",keyFile);

System.setProperty("javax.net.ssl.trustStorePassword",keyFilePass);

Java sslSocket 聊天實例

-----------------------------------------------------server-------------------------------------------------

package com.test.http;

/*

*SSL Socket的服務(wù)器端

*@Author lixingang

*/

import java.io.BufferedReader;

import java.io.FileInputStream;

import java.io.IOException;

import java.io.InputStreamReader;

import java.io.PrintStream;

import java.net.InetSocketAddress;

import java.net.SocketAddress;

import java.security.KeyManagementException;

import java.security.KeyStore;

import java.security.KeyStoreException;

import java.security.NoSuchAlgorithmException;

import java.security.UnrecoverableKeyException;

import java.security.cert.CertificateException;

import javax.net.ssl.KeyManagerFactory;

import javax.net.ssl.SSLContext;

import javax.net.ssl.SSLServerSocket;

import javax.net.ssl.SSLServerSocketFactory;

import javax.net.ssl.SSLSocket;

public class SSLServer {

public static void startSSLServer() throws IOException {

int port = 16666;// 監(jiān)聽端口

String keyFile = "c:testserverkey.jks";// 密鑰庫文件

String keyFilePass = "changeit";// 密鑰庫的密碼

String keyPass = "changeit";// 密鑰別名的密碼

SSLServerSocket sslsocket = null;// 安全連接套接字

KeyStore ks;// 密鑰庫

KeyManagerFactory kmf;// 密鑰管理工廠

SSLContext sslc = null;// 安全連接方式

// 初始化安全連接的密鑰

try {

ks = KeyStore.getInstance("JKS");

ks.load(new FileInputStream(keyFile), keyFilePass.toCharArray()); // 創(chuàng)建管理JKS 密鑰庫的X.509密鑰管理器

kmf = KeyManagerFactory.getInstance("SunX509");

kmf.init(ks, keyPass.toCharArray());

//構(gòu)造SSL 環(huán)境，指定SSL 版本為3.0，也可以使用TLSv1，但是SSLv3更加常用

sslc = SSLContext.getInstance("SSLv3");

//初始化SSL 環(huán)境。第二個參數(shù)是告訴JSSE 使用的可信任證書的來源，

//設(shè)置為null 是從javax.net.ssl.trustStore 中獲得證書。第三個參數(shù)是JSSE 生成的隨機數(shù)，

//這個參數(shù)將影響系統(tǒng)的安全性，設(shè)置為null 是個好選擇，可以保證JSSE 的安全性。

sslc.init(kmf.getKeyManagers(), null, null);

} catch (KeyManagementException ex) {

} catch (KeyStoreException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (NoSuchAlgorithmException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (CertificateException e) {

// TODO Auto-generated catch block

e.printStackTrace();

} catch (UnrecoverableKeyException e) {