https 和 SSL

1. HTTPS

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL表明它使用了HTTPS，但HTTPS存在不同於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通訊方法，現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面

HTTPS和HTTP的區別

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

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

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

四、http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

https的實現原理

有兩種基本的加解密算法類型

1）對稱加密 ：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；

2）非對稱加密 ：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

https的通信過程

圖2.1 https的通信過程

https通信的優點

1）客戶端產生的密鑰只有客戶端和服務器端能得到；

2）加密的數據只有客戶端和服務器端才能得到明文；

3）客戶端到服務端的通信是安全的。

HTTPS解決的問題

一、信任主機的問題.

採用https的服務器必須從CA （Certificate Authority）申請一個用於證明服務器用途類型的證書。該證書只有用於對應的服務器的時候，客戶端纔信任此主機。所以目前所有的銀行系統網站，關鍵部分應用都是https 的。客戶通過信任該證書，從而信任了該主機。其實這樣做效率很低，但是銀行更側重安全。這一點對我們沒有任何意義，我們的服務器，採用的證書不管是自己發佈的還是從公衆的地方發佈的，其客戶端都是自己人，所以我們也就肯定信任該服務器。 

二、通訊過程中的數據的泄密和被篡改

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

a) 主要目的是保證服務器就是他聲稱的服務器，這個跟第一點一樣。 

b) 服務端和客戶端之間的所有通訊，都是加密的。 

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

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

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

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

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

理解誤區

它的安全保護依賴瀏覽器的正確實現以及服務器軟件、實際加密算法的支持. 

一種常見的誤解是“銀行用戶在線使用https:就能充分徹底保障他們的銀行卡號不被偷竊。”實際上，與服務器的加密連接中能保護銀行卡號的部分，只有用戶到服務器之間的連接及服務器自身。並不能絕對確保服務器自己是安全的，這點甚至已被攻擊者利用，常見例子是模仿銀行域名的釣魚攻擊。少數罕見攻擊在網站傳輸客戶數據時發生，攻擊者會嘗試竊聽傳輸中的數據。 

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

SSL

SSL介紹

SSL安全套接層協議(Secure Socket Layer) 

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

當前版本爲3.0。它已被廣泛地用於Web瀏覽器與服務器之間的身份認證和加密數據傳輸。 

SSL協議位於TCP/IP協議與各種應用層協議之間，是一種國際標準的加密及身份認證通信協議,爲TCP提供一個可靠的端到端的安全服務，爲兩個通訊個體之間提供保密性和完整性(身份鑑別)。SSL協議可分爲兩層：SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。 

SSL協議特點

1）SSL協議可用於保護正常運行於TCP之上的任何應用協議，如HTTP、FTP、SMTP或Telnet的通信，最常見的是用SSL來保護HTTP的通信。

2）SSL協議的優點在於它是與應用層協議無關的。高層的應用協議（如HTTP、FTP、Telnet等）能透明地建立於SSL協議之上。

3）SSL協議在應用層協議之前就已經完成加密算法、通信密鑰的協商以及服務器的認證工作。在此之後應用層協議所傳送的數據都會被加密，從而保證通信的安全性。

4）SSL協議使用通信雙方的客戶證書以及CA根證書，允許客戶/服務器應用以一種不能被偷聽的方式通信，在通信雙方間建立起了一條安全的、可信任的通信通道。

5）該協議使用密鑰對傳送數據加密，許多網站都是通過這種協議從客戶端接收信用卡編號等保密信息。常用於交易過程中。

SSL功能

1)客戶對服務器的身份認證:

SSL服務器允許客戶的瀏覽器使用標準的公鑰加密技術和一些可靠的認證中心（CA）的證書，來確認服務器的合法性。

2)服務器對客戶的身份認證:

也可通過公鑰技術和證書進行認證，也可通過用戶名，password來認證。

3)建立服務器與客戶之間安全的數據通道:

SSL要求客戶與服務器之間的所有發送的數據都被髮送端加密、接收端解密，同時還檢查 數據的完整性

SSL協議工作的基本流程

1）接通階段：客戶機通過網絡向服務器打招呼，服務器迴應 

2）密碼交換階段：客戶機與服務器之間交換雙方認可的密碼，一般選用RSA密碼算法

3）會談密碼階段：客戶機器與服務器間產生彼此交談的會談密碼

4）檢驗階段：客戶機檢驗服務器取得的密碼

5）客戶認證階段：服務器驗證客戶機的可信度

6）結束階段：客戶機與服務器之間相互交換結束的信息

SSL安全實現原理

SSL 提供了用於啓動 TCP/IP 連接的安全性“信號交換”:

1. 這種信號交換導致客戶和服務器同意將使用的安全性級別，並履行連接的任何身份驗證要求.

2. 通過數字簽名和數字證書可實現瀏覽器和Web服務器雙方的身份驗證。

3.在用數字證書對雙方的身份驗證後，雙方就可以用保密密鑰進行安全的會話了。 

SSL協議說明

SSL協議具有兩層結構:

1)其底層是SSL記錄協議層（SSL Record Protocol Layer）

2)其高層是SSL握手協議層（SSL Handshake Protocol Layer）, 主要用來讓客戶端及服務器確認彼此的身分,爲了保護SSL記錄封包中傳送的數據，Handshake協議還能協助雙方選擇連接時所會使用的加密算法、MAC算法、及相關密鑰。 

SSL協議定義了兩個通信主體：客戶（client）和服務器（server）。其中，客戶是協議的發起者

在客戶/服務器結構中，應用層從請求服務和提供服務的角度定義客戶和服務器，而SSL協議則從建立加密參數的過程中所扮演的角色來定義客戶和服務器。  

SSL握手協議包含四個階段:第一個階段建立安全能力;第二個階段服務器鑑別和密鑰交換;第三個階段客戶鑑別(可選的)和密鑰交換;第四個階段完成握手協議。 

SSL協議工作的基本流程

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

用戶認證階段:

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

SSL流程

第一步：身份驗證

第二步：發明密語規則

第三步：密語規則共享

第四步：進行安全通信

簡要描述

1） 客戶端向服務器發送一個開始信息“Hello”以便開始一個新的會話連接

2） 服務器根據客戶的信息確定是否需要生成新的主密鑰，如需要則服務器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息

3） 客戶根據收到的服務器響應信息，產生一個主密鑰，並用服務器的公開密鑰加密後傳給服務器

4） 服務器恢復該主密鑰，並返回給客戶一個用主密鑰認證的信息，以此讓客戶認證服務器。(以上爲服務端認證)

5） 服務器已經通過了客戶認證，這一階段主要完成對客戶對服務端的認證。經認證的服務器發送一個提問給客戶，客戶則返回（數字）簽名後的提問和其公開密鑰，從而向服務器提供認證。（客戶端認證）

詳細描述

SSL 協議既用到了公鑰加密技術又用到了對稱加密技術，對稱加密技術雖然比公鑰加密技術的速度快，可是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議非常有效的讓客戶和服務器之間完成相互之間的身份認證，其主要過程如下： 

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

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

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

4)用戶端隨機產生一個用於後面通訊的“對稱密碼”，然後用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中獲得）對其加密，然後將加密後的“預主密碼”傳給服務器。 (服務端驗證成功)

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

6)如果服務器要求客戶的身份認證，服務器必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，爲客戶提供證書的CA 是否可靠，發行CA 的公鑰能否正確解開客戶證書的發行CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務器將用自己的私鑰解開加密的“預主密碼”，然後執行一系列步驟來產生主通訊密碼（客戶端也將通過同樣的方法產生相同的主通訊密碼）。 

7)服務器和客戶端用相同的主密碼即“通話密碼”，一個對稱密鑰用於SSL 協議的安全數據通訊的加解密通訊。同時在SSL 通訊過程中還要完成數據通訊的完整性，防止數據通訊中的任何變化。 

8)客戶端向服務器端發出信息，指明後面的數據通訊將使用的步驟7中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。 

9)服務器向客戶端發出信息，指明後面的數據通訊將使用的步驟7中的主密碼爲對稱密鑰，同時通知客戶端服務器端的握手過程結束。 

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

SSL缺點

1）SSL協議需要在握手之前建立TCP連接，因此不能對UDP應用進行保護。

2）爲了不致於由於安全協議的使用而導致網絡性能大幅下降SSL協議並不是默認地要求進行客戶鑑別

CA

Ca介紹

電子商務認證授權機構（CA, Certificate Authority），也稱爲電子商務認證中心，是負責發放和管理數字證書的權威機構，並作爲電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。 

CA中心爲每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。CA機構的數字簽名使得攻擊者不能僞造和篡改證書。在SET交易中，CA不僅對持卡人、商戶發放證書，還要對獲款的銀行、網關發放證書。

CA是證書的簽發機構,它是PKI(Public Key Infrastructure，公鑰基礎設施)的核心。CA是負責簽發證書、認證證書、管理已頒發證書的機關。它要制定政策和具體步驟來驗證、識別用戶身份，並對用戶證書進行簽名，以確保證書持有者的身份和公鑰的擁有權。

CA 也擁有一個證書（內含公鑰）和私鑰。網上的公衆用戶通過驗證 CA 的簽字從而信任 CA ，任何人都可以得到 CA 的證書（含公鑰），用以驗證它所簽發的證書。 

如果用戶想得到一份屬於自己的證書，他應先向 CA 提出申請。在 CA 判明申請者的身份後，便爲他分配一個公鑰，並且 CA 將該公鑰與申請者的身份信息綁在一起，併爲之簽字後，便形成證書發給申請者。 

如果一個用戶想鑑別另一個證書的真僞，他就用 CA 的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認爲是有效的。

CA認證 證書

證書實際是由證書籤證機關（CA）簽發的對用戶的公鑰的認證。 

證書的內容包括：電子簽證機關的信息、公鑰用戶信息、公鑰、權威機構的簽字和有效期等等。目前，證書的格式和驗證方法普遍遵循X.509 國際標準。  

如何在電子文檔上實現簽名的目的呢？我們可以使用數字簽名。RSA公鑰體制可實現對數字信息的數字簽名，方法如下： 

信息發送者用其私鑰對從所傳報文中提取出的特徵數據（或稱數字指紋）進行RSA算法操作，以保證發信人無法抵賴曾發過該信息（即不可抵賴性），同時也確保信息報文在傳遞過程中未被篡改（即完整性）。當信息接收者收到報文後，就可以用發送者的公鑰對數字簽名進行驗證。 

在數字簽名中有重要作用的數字指紋是通過一類特殊的散列函數(HASH函數) 生成的。對這些HASH函數的特殊要求是： 

1．接受的輸入報文數據沒有長度限制； 

2．對任何輸入報文數據生成固定長度的摘要(數字指紋)輸出； 

3．從報文能方便地算出摘要； 

4．難以對指定的摘要生成一個報文，而由該報文可以算出該指定的摘要； 

5．難以生成兩個不同的報文具有相同的摘要。

CA認證驗證

接收方在收到信息後用如下的步驟驗證您的簽名： 

1．使用自己的私鑰將信息轉爲明文； 

2．使用發信方的公鑰從數字簽名部分得到原摘要； 

3．收方對您所發送的源信息進行hash運算，也產生一個摘要； 

4．收方比較兩個摘要，如果兩者相同，則可以證明信息簽名者的身份。 

如果兩摘要內容不符，會說明:

可能對摘要進行簽名所用的私鑰不是簽名者的私鑰，這就表明信息的簽名者不可信；也可能收到的信息根本就不是簽名者發送的信息，信息在傳輸過程中已經遭到破壞或篡改。

CA認證 數字證書

數字證書爲實現雙方安全通信提供了電子認證。在因特網、公司內部網或外部網中，使用數字證書實現身份識別和電子信息加密。數字證書中含有密鑰對（公鑰和私鑰）所有者的識別信息，通過驗證識別信息的真僞實現對證書持有者身份的認證。 

CA認證 使用數字證書

數字證書在用戶公鑰後附加了用戶信息及CA的簽名。公鑰是密鑰的一部分，另一部分是私鑰。公鑰公之於衆，誰都可以使用。私鑰只有自己知道。由公鑰加密的信息只能由與之相對應的私鑰解密。爲確保只有某個人才能閱讀自己的信件，發送者要用收件人的公鑰加密信件；收件人便可用自己的私鑰解密信件。同樣，爲證實發件人的身份，發送者要用自己的私鑰對信件進行簽名；收件人可使用發送者的公鑰對簽名進行驗證，以確認發送者的身份。 

圖1.1 發送數據處理過程

圖1.2接收數據處理過程

在線交易中您可使用數字證書驗證對方身份。用數字證書加密信息，可以確保只有接收者才能解密、閱讀原文，信息在傳遞過程中的保密性和完整性。有了數字證書網上安全才得以實現，電子郵件、在線交易和信用卡購物的安全才能得到保證。

密鑰、密鑰對、公鑰、證書、私鑰、jks、keystore、truststore、cer、pfx的區別

密鑰:  公鑰+私鑰的統稱。

密鑰對：公鑰(證書)和私鑰成對存在。

通信雙方各持有自己的私鑰和對方的公鑰。自己的私鑰需密切保護，而公鑰是公開給對方的。在windows下，單獨存在的公鑰一般是後綴爲.cer的文件

公鑰的兩個用途：

1。驗證對方身份：防止其他人假冒對方發送數據給你。

2。解密。

私鑰的兩個用途：

1。表明自己身份：除非第三方有你私鑰，否則無法假冒你發送數據數據給對方。

2。加密。

jks(java key store)：

java用的存儲密鑰的容器。可以同時容納n個公鑰或私鑰，後綴一般是.jks或者.keystore或.truststore等，千奇百怪。不管什麼後綴，它就是一個容器，各個公司或機構叫法不同而已。比如把只包含"受信任的公鑰"的容器存成.truststore文件等。

用jdk\bin目錄下的keytool.exe對其進行查看，導入，導出，刪除，修改密碼等各種操作。

可以對jks容器加入密碼，輸入正確纔可以操作此容器中密鑰。

還有一個密碼的概念與上者不同，是jks中存儲着的私鑰的密碼，通常是絕密的。

pfx：

和jks功能相同但文件格式不同，pfx是瀏覽器用的。

可以用一些工具程序把pfx轉化成jks格式供java程序使用(如銀行只提供了pfx)。

常見的幾種https系統的訪問

經https協議的數據經過加密傳輸，防止第三方監聽，冒充和篡改。

1.不需要用戶做任何操作，比如https://www.verisign.com/

這是因爲此公鑰是合法的(公鑰是可信任的機構頒發，和實際域名吻合，而且沒有到期)。用IE訪問時空白處點右鍵可以查看公鑰信息。

2.https的頁面會彈出公鑰確認提示

公鑰不合法(不是可信任的機構頒發，和實際域名不吻合，已到期)，但用戶點“是”即表示忽略危險，繼續訪問。

3.需要往瀏覽器倒入一個文件纔可訪問的

一般是銀行在線交易等特別需要安全的場合，站方(銀行)需要驗證訪客身份(如要確認必須是已註冊的網銀商戶)，需要在瀏覽器中導入含有訪客私鑰的pfx文件。

如果java程序訪問此地址時在jre默認的信任庫中找不到對方證書的頒發機構，則會拋出安全方面的異常。所以要將站方公鑰存進一個jks，並在環境變量中設定，表明信任此庫中的公鑰，纔可以正常訪問。在瀏覽器中查看站方公鑰時，把公鑰導出(一般是cer後綴)，然後用keytool.exe手工將此cer導入一個jks

TOMCAL配置單項認證

在命令提示符窗口，進入Tomcat目錄，執行以下命令： 
keytool -genkey -alias tomcat -keyalg RSA -keypass changeit -storepass changeit -keystore server.keystore -validity 3600 
通過以上步驟生成server.keystore證書文件 
將servlet.xml的SSL註釋打開

<!– Define a SSL HTTP/1.1 Connector on port 8443 –>  
<Connector protocol="org.apache.coyote.http11.Http11Protocol"  
port="8443" maxHttpHeaderSize="8192"  
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"  
enableLookups="false" disableUploadTimeout="true"  
acceptCount="100" scheme="https" secure="true"  
clientAuth="false" sslProtocol="TLS"  
keystoreFile="server.keystore"  
keystorePass="changeit"/>  
到這一步訪問基本配置完成.

一般Tomcat默認的SSL端口號是8443，但是對於SSL標準端口號是443，這樣在訪問網頁的時候，直接使用https而不需要輸入端口號就可以訪問，如https://loalhost/webserver 
想要修改端口號，需要修改Tomcat的server.xml文件：

1) non-SSL HTTP/1.1 Connector定義的地方，一般如下： 
<Connector port="80" maxHttpHeaderSize="8192" 
maxThreads="500" minSpareThreads="25" maxSpareThreads="75" 
enableLookups="false" redirectPort="443" acceptCount="100" 
connectionTimeout="20000" disableUploadTimeout="true" /> 
將其中的redirectPort端口號改爲：443

2)SSL HTTP/1.1 Connector定義的地方，修改端口號爲：443，如下： 
<Connector port="443" maxHttpHeaderSize="8192" 
maxThreads="150" minSpareThreads="25" 
maxSpareThreads="75" 
enableLookups="false"  
disableUploadTimeout="true" 
acceptCount="100" scheme="https" 
secure="true" 
clientAuth="false" sslProtocol="TLS"  
keystoreFile="conf/tomcat.keystore"  
keystorePass="123456" />

3)AJP 1.3 Connector定義的地方(apache就是通過AJP協議與tomcat進行通信的)，修改redirectPort爲443，如下： 
<Connector port="8009"  
enableLookups="false" redirectPort="443" protocol="AJP/1.3" /> 
重新啓動Tomcat就可以了。到這一步可以形成訪問方式 http://ip/item

使用java內置keytool配置tomcat雙向SSL認證

在Tomcat 6中配置SSL雙向認證是相當容易的，本文將介紹如何使用JDK的keytool來爲Tomcat配置雙向SSL認證。 
系統需求： 
JDK 5.0 
Tomcat 6.0.16 
第一步：爲服務器生成證書 
使用keytool爲Tomcat生成證書，假定目標機器的域名是“localhost”，keystore文件存放在“C:/tomcat.keystore”，口令爲“password”，使用如下命令生成：

1. keytool -genkey -v -alias tomcat -keyalg RSA -keystore c:/tomcat.keystore -dname

2. "CN=localhost,OU=,O=,L=,ST=,C=" -storepass password -keypass password

複製代碼

如果Tomcat所在服務器的域名不是“localhost”，應改爲對應的域名，如“www.sina.com.cn”，否則瀏覽器會彈出警告窗口，提示用戶證書與所在域不匹配。在本地做開發測試時，應填入“localhost” 
；證書如果沒有指定有效期，默認爲90天 
第二步：爲客戶端生成證書 
下一步是爲瀏覽器生成證書，以便讓服務器來驗證它。爲了能將證書順利導入至IE和Firefox，證書格式應該是PKCS12，因此，使用如下命令生成：

1. keytool -genkey -v -alias mykey -keyalg RSA -storetyp PKCS12 C:/my.p12

2. -dname "CN=localhost,OU=,O=,L=,ST=,C=" -storepas password -keypass password

複製代碼

對應的證書庫存放在“C:/my.p12”，客戶端的CN可以是任意值。稍候，我們將把這個“my.p12”證書庫導入到IE和Firefox中。 
第三步：讓服務器信任客戶端證書 
由於是雙向SSL認證，服務器必須要信任客戶端證書，因此，必須把客戶端證書添加爲服務器的信任認證。由於不能直接將PKCS12格式的證書庫導入，我們必須先把客戶端證書導出爲一個單獨的CER文件，使用如下命令：

1. keytool -export -alias mykey -keystore cL/my.p12 -storetype PKCS12 -storepass password -rfc -file C:/my.cer

複製代碼

通過以上命令，客戶端證書就被我們導出到“C:/my.cer”文件了。下一步，是將該文件導入到服務器的證書庫，添加爲一個信任證書：

1. keytool -import -v -file C:/my.cer -keystore C:/tomcat.keystore -storepass password

複製代碼

通過list命令查看服務器的證書庫，我們可以看到兩個輸入，一個是服務器證書，一個是受信任的客戶端證書：

1. keytool -list c:/tomcat.keystore -storepass password

複製代碼

第四步：配置Tomcat服務器 
打開Tomcat根目錄下的/conf/server.xml，找到如下配置段，修改如下：

1. <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

2. maxThreads="150" scheme="https" secure="true"

3. clientAuth="true" sslProtocol="TLS"

4. keystoreFile="C:/tomcat.keystore" keystorePass="password"

5. truststoreFile="C:/tomcat.keystore" truststorePass="password"

6. />

複製代碼

其中，clientAuth指定是否需要驗證客戶端證書，如果該設置爲“false”，則爲單向SSL驗證，SSL配置可到此結束。如果clientAuth設置爲“true”，表示強制雙向SSL驗證，必須驗證客戶端證書。如果clientAuth設置爲“want”，則表示可以驗證客戶端證書，但如果客戶端沒有有效證書，也不強制驗證。 
第五步：導入客戶端證書 
如果設置了clientAuth="true"，則需要強制驗證客戶端證書。雙擊“C:/my.p12”即可將證書導入至IE： 
導入證書後，即可啓動Tomcat，用IE進行訪問。如果需要用FireFox訪問，則需將證書導入至FireFox：

配置Flex使用安全通道

1.在services-config.xml中創建節點

<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">

<endpointurl="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure"class="flex.messaging.endpoints.SecureAMFEndpoint" />

<properties>

<add-no-cache-headers>false</add-no-cache-headers>

</properties>

</channel-definition>

2.修改自定義通道的url和class，如：

<channel-definition id="resource-streaming-amf"

class="mx.messaging.channels.SecureStreamingAMFChannel">

<endpoint url=https://{server.name}:{server.port}/{context.root}/messagebroker/resourcestreamingamf

class="flex.messaging.endpoints.SecureStreamingAMFEndpoint" />

3.修改proxy-config.xml中的default-channels，如：

    <default-channels>

        <channel ref="my-secure-amf"/>

</default-channels>

4.修改remoting-config.xml中的default-channels,如：

<default-channels>

<channel ref="my-secure-amf" />

</default-channels>

5.在as中使用_remoteObject.endpoint的地方修改value：

https://{server.name}:{server.port}/項目名稱/messagebroker/amfsecure