1.術語

1.1 SSL

TLS 與 SSL TLS 的前身是 SSL。其是一個用于在應用程序之間進行通信時保障隱私的協議。除非另有說明，本文中認為 TLS 與 SSL 是等價的。

OpenSSL 簡單地說,OpenSSL是SSL的一個實現,SSL只是一種規范.理論上來說,SSL這種規范是安全的,目前的技術水平很難破解,但SSL的實現就可能有些漏洞,如著名的”心臟出血”.OpenSSL還提供了一大堆強大的工具軟件,強大到90%我們都用不到

1.2 密鑰相關術語

公鑰、私鑰 公鑰和私鑰就是俗稱的不對稱加密方式，是從以前的對稱加密（使用用戶名與密碼）方式的提高。 一個私鑰可以驗證與其對應的用來對數據進行加密的證書和公鑰。其決不公開提供。 公鑰和私鑰是成對的，它們互相解密。非對稱密鑰密碼的主要應用就是公鑰加密和公鑰認證，而公鑰加密的過程和公鑰認證的過程是不一樣的：公鑰加密，私鑰解密。私鑰數字簽名，公鑰認證。 比如，我用你的公鑰給這個郵件加密，這樣就保證這個郵件不被別人看到，而且保證這個郵件在傳送過程中沒有被修改。你收到郵件后，用你的私鑰就可以解密，就能看到內容。 其次我用我的私鑰給這個郵件加密，發送到你手里后，你可以用我的公鑰解密。因為私鑰只有我手里有，這樣就保證了這個郵件是我發送的。 當A->B資料時，A會使用B的公鑰加密，這樣才能確保只有B能解開，否則普羅大眾都能解開加密的訊息，就是去了資料的保密性。驗證方面則是使用簽 驗章的機制，A傳資料給大家時，會以自己的私鑰做簽章，如此所有收到訊息的人都可以用A的公鑰進行驗章，便可確認訊息是由 A 發出來的了。

摘要 對需要傳輸的文本，做一個HASH計算，一般采用SHA1，SHA2來獲得。

簽名 使用私鑰對需要傳輸的文本的摘要進行加密，得到的密文即被稱為該次傳輸過程的簽名。

簽名認證 數據接收端，拿到傳輸文本，但是需要確認該文本是否就是發送發出的內容，中途是否曾經被篡改。因此拿自己持有的公鑰對簽名進行解密（密鑰對中的一種密鑰加密的數據必定能使用另一種密鑰解密。），得到了文本的摘要，然后使用與發送方同樣的HASH算法計算摘要值，再與解密得到的摘要做對比，發現二者完全一致，則說明文本沒有被篡改過。

基于公鑰的加密過程 比如有兩個用戶Alice和Bob，Alice想把一段明文通過雙鑰加密的技術發送給Bob，Bob有一對公鑰和私鑰，那么加密解密的過程如下： Bob將他的公開密鑰傳送給Alice。Alice用Bob的公開密鑰加密她的消息，然后傳送給Bob。Bob用他的私人密鑰解密Alice的消息。Alice使用Bob的公鑰進行加密，Bob用自己的私鑰進行解密。

基于公鑰的認證過程 身份認證和加密就不同了，主要用來鑒別用戶的真偽。這里我們只要能夠鑒別一個用戶的私鑰是正確的，就可以鑒別這個用戶的真偽。 還是Alice和Bob這兩個用戶，Alice想讓Bob知道自己是真實的Alice，而不是假冒的，因此Alice只要使用私鑰對文件簽名發送給Bob，Bob使用Alice的公鑰對文件進行解密，如果可以解密成功，則證明Alice的私鑰是正確的，因而就完成了對Alice的身份鑒 別。整個身份認證的過程如下： Alice用她的私人密鑰對文件加密，從而對文件簽名。Alice將簽名的文件傳送給Bob。Bob用Alice的公鑰解密文件，從而驗證簽名。Alice使用自己的私鑰加密，Bob用Alice的公鑰進行解密。

證書（cert） 包含了提供者信息等一些額外元數據的公鑰/私鑰對的公鑰部分。它可以被自由的提供給任何人。

在簽名的過程中，有一點很關鍵，收到數據的一方，需要自己保管好公鑰，但是要知道每一個發送方都有一個公鑰，那么接收數據的人需要保存非常多的公鑰，這根本就管理不過來。并且本地保存的公鑰有可能被篡改替換，無從發現。怎么解決這一問題？由一個統一的證書管理機構來管理所有需要發送數據方的公鑰，對公鑰進行認證和加密。這個機構也就是我們常說的CA。

認證加密后的公鑰，即是證書，又稱為CA證書，證書中包含了很多信息，最重要的是申請者的公鑰。數字證書用來使用戶找到該授信機構的公鑰。

證書頒發機構（CA） 一個頒發數字證書的公司。對于 SSL/TLS 證書，也有少數供應商（例如 Symantec/Versign/Thawte、Comodo、GoDaddy）的證書囊括了大多數瀏覽器和操作系統。它們的目的是成為一個“可信的第三方”。

1.3 證書標準

X.509 用于描述證書的格式和用法的一個規范。主要定義了證書中應該包含哪些內容.其詳情可以參考RFC5280,SSL使用的就是這種證書標準.

1.4 編碼格式

同樣的X.509證書,可能有不同的編碼格式,目前有以下兩種編碼格式.

PEM PRivacy Enhanced Mail,打開看文本格式,以”—–BEGIN…”開頭, “—–END…”結尾,內容是BASE64編碼. 查看PEM格式證書的信息:openssl x509 -in certificate.pem -text -noout Apache和*NIX服務器偏向于使用這種編碼格式.

DER Distinguished Encoding Rules,打開看是二進制格式,不可讀. 查看DER格式證書的信息:openssl x509 -in certificate.der -inform der -text -noout java和Windows服務器偏向于使用這種編碼格式.

1.5 文件擴展名

這是比較誤導人的地方,雖然我們已經知道有PEM和DER這兩種編碼格式,但文件擴展名并不一定就叫”PEM”或者”DER”,常見的擴展名除了PEM和DER還有以下這些,它們除了編碼格式可能不同之外,內容也有差別,但大多數都能相互轉換編碼格式.

key 通常用來存放一個公鑰或者私鑰,并非X.509證書,編碼同樣的,可能是PEM,也可能是DER. 查看KEY的辦法:openssl rsa -in mykey.key -text -noout 如果是DER格式的話,同理應該這樣了:openssl rsa -in mykey.key -text -noout -inform der

crt crt應該是certificate的三個字母,其實還是證書的意思,常見于*NIX系統,有可能是PEM編碼,也有可能是DER編碼,大多數應該是PEM編碼,相信你已經知道怎么辨別.

cer 還是certificate,還是證書,常見于Windows系統,同樣的,可能是PEM編碼,也可能是DER編碼,大多數應該是DER編碼.

csr Certificate Signing Request,即證書簽名請求,這個并不是證書,用私鑰生成的一個文件。是向權威證書頒發機構獲得簽名證書的申請, CA 則使用其私鑰對csr進行數字簽名，并創建一個已簽名的證書。然后瀏覽器可以使用 CA 提供的證書來驗證新的證書是否已被 CA 批準。 其核心內容是一個公鑰(當然還附帶了一些別的信息),在生成這個申請的時候,同時也會生成一個私鑰,私鑰要自己保管好.(?) 查看的辦法:openssl req -noout -text -in my.csr (如果是DER格式的話照舊加上-inform der,這里不寫了)

PFX/P12 predecessor of PKCS#12,對*nix服務器來說,一般CRT和KEY是分開存放在不同文件中的,但Windows的IIS則將它們存在一個PFX文件中,(因此這個文件包含了證書及私鑰)這樣會不會不安全？應該不會,PFX通常會有一個”提取密碼”,你想把里面的東西讀取出來的話,它就要求你提供提取密碼,PFX使用的時DER編碼,如何把PFX轉換為PEM編碼？ openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes 這個時候會提示你輸入提取代碼. for-iis.pem就是可讀的文本. 生成pfx的命令類似這樣:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt

其中CACert.crt是CA(權威證書頒發機構)的根證書,有的話也通過-certfile參數一起帶進去.這么看來,PFX其實是個證書密鑰庫.

JKS 即Java Key Storage,這是Java的專利,跟OpenSSL關系不大,利用Java的一個叫”keytool”的工具,可以將PFX轉為JKS,當然了,keytool也能直接生成JKS,不過在此就不多表了.

2.公鑰、私鑰、證書的生成

3.公鑰、私鑰、證書的使用

在HTTPS協議的握手階段是公鑰、私鑰、證書的典型使用場景。HTTPS握手的典型時序圖如下： ???

上圖中實線部分是必須的，虛線部分是可選的。該流程完成了兩個任務：服務器身份的驗證、加密傳輸對稱加密密鑰。 1、client hello和 server hello表示雙方要建立一個加密會話。 2、服務器把數字證書傳輸給客戶端，證書中包含服務器公鑰，客戶端用公鑰解析證書中的數字簽名，可以驗證服務器的身份。 3、Server Hello Done表示hello 流程結束。 4、客戶端生成一個對稱加密密鑰，用于實際數據的加密傳輸，并用服務器的公鑰加密，把對生成的密鑰傳遞給服務器。同時攜帶一個用剛剛生成的加密密鑰加密的“client finished”。 5、服務器收到對稱加密密鑰，并嘗試用該密鑰解密加密字段，如能得到明文“client finished”，認為該密鑰有效，可以用于之后的數據加密傳輸。同時用該密鑰加密“server finished”，傳遞給客戶端。 6、客戶端用對稱機密密鑰解密，如能得到明文“server finished”，客戶端認為該服務器已經正確的接收到對稱密鑰。 7、加密數據傳輸開始。 虛線部分是服務器端要求驗證客戶身份。

references

1.http://www.CUOXin.com/guogangj/p/4118605.html 2.http://www.oschina.net/translate/everything-you-ever-wanted-to-know-about-ssl 3.http://blog.csdn.net/sealyao/article/details/5761747