07.25 深入淺出 SSL 管理配置實戰

我們生活在一個信息大爆炸的時代，幾乎每天都在和互聯網打交道，購物、網銀轉賬、支付寶付款、搜索信息、查看郵件、觀看視頻、微信聊天、上網衝浪、閱讀新聞等，無不時時刻刻在和網絡打交道。那如何保護網絡安全就相當重要了，其方法有很多，其中應用最為廣泛的就是使用 SSL 來保護 C/S 或者 B/S 的通信安全。

SSL 能夠幫助系統在客戶端和服務器之間建立一條安全通信通道。SSL 安全協議是由 Netscape Communication 公司在 1994 年設計開發，SSL 依賴於加密算法、極難竊聽、有較高的安全性，因此 SSL 協議已經成為網絡上最常用的安全保密通信協議，該安全協議主要用來提供對用戶和服務器的認證；對傳送的數據進行加密和隱藏；確保數據在傳送中不被改變，即數據的完整性，現已成為該領域中全球化的標準。

很多時候，我們並不知道如何管理和配置 SSL 證書。本課程作者將用實際的例子，手把手一步一步教大家如何使用工具生成、管理、配置 SSL 證書，該課程是一系列基礎教程，涉及面廣，先以一個 Tomcat 的 SSL 的配置實戰為例子，然後一步步分享 SSL 的基礎必備知識和管理工具。

認真學完這個系列內容，並按照提供的例子進行實戰，將會深入理解 SSL 的概念、目的、證書的申請、管理、配置，基本上覆蓋行業的大部分典型的應用場景，從而可以輕鬆超越 80% 的人，快速成為一個配置、管理、創建 SSL 證書的高手。

注意： 為了描述和表達方便，本達人課內容把 SSL 和 TLS 作為一個整體（SSL/TLS）來對待，沿用了大家熟悉的稱呼 SSL。所有後面提到的有關 SSL 的關鍵字，其實指的都是 SSL 和 TLS。

朱清雲，架構師、CSDN 博客專家，從事架構設計 8 年有餘，曾先後就職於世界 500 強國企和美資外企。目前感興趣的研究方向：企業應用集成、物聯網、區塊鏈、DevOps 自動化運維、大數據及人工智能。即將出版《MQTT 權威指南》一書，希望通過這個平臺認識更多的朋友。

我們生活在一個信息大爆炸的時代，幾乎每天都在和互聯網打交道，購物、網銀轉賬、支付寶付款、搜索信息、查看郵件、觀看視頻、微信聊天、上網衝浪、閱讀新聞，無不時時刻刻在和網絡打交道。如果說互聯網是一個江湖，江湖險惡，江湖人心難測，難免有一些不懷好意的人對你的個人信息感興趣，比如信用卡信息、身份證信息、網銀的賬號密碼、特殊癖好等，那麼如何保障當私人的隱秘信息從電腦手機上發送到遠端的服務器上的時候，能把我們的隱私數據加密起來，即使別人得到了加密的數據，也很難解開，相當於給我們的信息加上了一把鎖，方法有很多，但是目前流行和使用最廣的技術手段就是 SSL（Security Socket Layer，安全套接層協議）。

enter image description here

SSL（Secure Socket Layer）翻譯成中文就是“安全套接層”，SSL 能夠幫助系統在客戶端和服務器之間建立一條安全通信通道。SSL 安全協議是由 Netscape Communication 公司在 1994 年設計開發，SSL 依賴於加密算法（在後面的章節中會提到）、極難竊聽、有較高的安全性，因此 SSL 協議已經成為網絡上最常用的安全保密通信協議，該安全協議主要用來提供對用戶和服務器的認證；對傳送的數據進行加密和隱藏；確保數據在傳送中不被改變，即數據的完整性，現已成為該領域中全球化的標準。

舉一個日常生活中的簡單例子，當我們用電腦打開一些常用的網站時，比如京東、淘寶、百度等，如果心細的讀者會發現，不管是用微軟的瀏覽器，還是谷歌瀏覽器，其瀏覽器的地址欄上方有一把鎖，這把鎖其實代表的就是 SSL 協議，是 SSL 在 HTTP 協議上的應用，用鎖鎖住我們的私密信息，防止私密信息在訪問網站的過程中被第三方程序或者不懷好意的人監聽到，如果沒有這把保護我們通信安全的 SSL 鎖的話，我們的信息則非常容易被第三方監聽到。

enter image description here

君不見微信的小程序，服務器的 API 訪問必須是支持 SSL 的 HTTPS 協議；谷歌也宣佈對其所有的網站支持 HTTPS（Http Over SSL）協議；通過激活 SSL 協議，實現數據信息在客戶端和服務器之間的加密傳輸，可以防止數據信息的洩露，保證了雙方傳遞信息的安全性，而且用戶可以通過服務器證書驗證他所訪問的網站是否是真實可靠。

值的一提的是，SSL 有很多的版本，SSL 於 1995 年發佈了 3.0 的版本，但是後來，在 1999 年，IEFT（The Internet Engineering Task Force，互聯網工程任務組）在 SSL 3.0 的基礎上發佈了 TLS 1.0（Transport Layer Security，安全套接層）協議，其標準名稱編號為 RFC 2246，實際上相當於 SSL 3.1。

2006 年 TLS 1.1 以標準編號為 RFC 4346 形式發佈，該版本增加了對 CBC 攻擊的對策並把 AES 加入對稱密碼算法集中，進一步增強了其安全性，此外在 TLS 1.1 中把 AES 也加入到對稱加密算法中。

2008 年 TLS 1.2 以標準標號為 RFC 5246 形式發佈，該版本主要的變更就是：偽隨機函數（PRF）中的 MD5-SHA-1 組合被 SHA-256 取代，可以使用密碼套件指定的 PRF。

目前所有的正在使用的 SSL/TLS 的版本信息如下：

值得一提的是 TLS 1.3 將在今年，也就是2018年3月21日已經被批准成為正式的 TLS 標準。

在本達人課後面的課程裡，會有章節來分享如何讓你知道在和服務器進行 SSL 通信時，SSL 的具體版本到底是什麼？敬請期待。

注意： 為了描述和表達方便，本達人課內容把 SSL 和 TLS 作為一個整體（SSL/TLS）來對待，沿用了大家熟悉的稱呼 SSL。所有後面提到的有關 SSL 的關鍵字，其實指的都是 SSL 和 TLS。

下面通過一個實際的實驗，給大家分享一下，為什麼 SSL 能夠保護我們在通信過程中的安全，為了簡單起見，咱們以 SSL 應用於 HTTP 協議為例，通過快速搭建一個簡單的 Web 服務器，來觀察在使用 SSL 和不使用 SSL 時，我們的數據是如何傳輸的。

讀者可以先到 Tomcat 的網站下載一個 Window 的安裝包，下載完成後，解壓縮到指定的文件夾下， 比如，D:\\apache-tomcat-9.0.1，然後在 D:\\apache-tomcat-9.0.1\\webapps\\examples\\ 目錄下加入一個 ssldemo.html 的文件，其內容如下：

然後啟動 Tomcat 9，在打開瀏覽器之前，請先下載一個名字叫 Fiddler 的軟件，百度百科對 Fiddler 的介紹如下：

Fiddler 是一個 HTTP 協議調試代理工具，它能夠記錄並檢查所有你的電腦和互聯網之間的 HTTP 通訊，設置斷點，查看所有的“進出” Fiddler 的數據（指 Cookie、HTML、JS、CSS 等文件，這些都可以讓你胡亂修改的意思）。Fiddler 要比其他的網絡調試器要更加簡單，因為它不僅僅暴露 HTTP 通訊還提供了一個用戶友好的格式。

我們可以單擊這裡，下載免費的工具並安裝。

假設已經安裝並打開了 Fiddler，在瀏覽器中輸入下面的地址，將看到下面的內容：http://localhost:8080/examples/ssldemo.html：

enter image description here

這個時候 Fiddler 監測到的內容如下：

enter image description here

根據 Fiddler 截獲的信息，我們知道在客戶端和服務器傳輸的信息完全是明文，如果有不懷好意的人或者黑客，截取了瀏覽器和這個站點之間的所有 HTTP 請求的話，其上面傳輸的信息，所見即所得，被一覽無餘。在瀏覽器和 Web 服務器之間，如果傳輸只是一般的文本信息，比如 CSDN 的博客等，問題也不大。但是如果傳輸的是銀行賬號和密碼呢？如果傳輸的是身份證信息或者信用卡信息呢？如果沒有一種很好的機制去保護的話，如果被監聽到了，後果將是災難性的，那如何破這個局呢？其中一種很常見的方式，就是搭建一個基於 SSL 的 Web 服務器，讓所有的信息通過 HTTPS 協議來傳輸。

下面筆者來配置一下 Tomcat 服務器，讓其來支持 HTTPS，下面列出了其具體步驟。

1.創建一個 SSL 的證書

假設我們機器上已經安裝了 JDK 並配置了 Java Home，然後打開命令行，確保 keytool 命令能用，如果不用請到 JDK 的安裝目錄下 bin 子目錄尋找，在命令行中輸入下面的命令：

然後按照提示，輸入 first name and last name 等相關信息，這樣就會生成一個證書對並存儲到 tomcat.jks 文件中，另外在生成 tomcat.jks 文件的時候，其會讓我們提示輸入密碼，假設輸入的密碼是：changeit。

2.保存好 JKS 文件

把 tomcat.jks 複製到 Tomcat 的安裝目錄下，筆者的安裝目錄是：D:\\apache-tomcat-9.0.1，所以這裡將其複製到 D:\\apache-tomcat-9.0.1\\conf\\tomcat.jks，當然也可以不用複製，但是需要知道 tomcat.jks 文件的全路徑，因為這個路徑在後面需要用到。

3.配置 Tomcat 的 Server.xml 文件

在 Tomcat 的安裝目錄下打開 server.xml 文件，筆者的電腦上是，D:\\apache-tomcat-9.0.1\\conf\\server.xml 文件，然後編輯這個文件，把已有的 8080 端口的 Connector 註釋起來，然後加入下面新的 8443 端口的 Connector。

enter image description here

文本形式的配置如下：

4.重啟啟動 Tomcat 服務器

在瀏覽器輸入 https://localhost:8443/examples/ssldemo.html 網址，此時，我們發現其走的 HTTPS 協議，也就是用 SSL 保護了的 HTTP 協議，這個時候再回頭來看 Fiddler 監聽的信息的結果。

enter image description here

從上面的結果來看，我們的 Fiddler 監聽到的已經是加過密的信息，看了這些信息，壓根就不知道 Web 服務器向瀏覽器傳輸了什麼信息，因為其是密文的，只有知道其秘鑰的工具才能把其破解成明文，這樣媽媽再也不同擔心我們在網上傳輸個人的信息了。

在進行 SSL 實戰之旅開始時，這裡有必要給大家普及一些和 SSL 相關的核心概念，這樣大家在閱讀後面的文章時，如果遇到這些基本核心概念的時候，能夠明白說的是什麼；若已經對下面的這些核心概念已瞭解甚至精通了，可以跳過本節內容，直接進入後面的章節內容。

大家都有過出門住酒店或者買火車票飛機票的經歷，當我們買飛機票和火車票的時候，取票點會讓我們出示身份證證件，通過身份證就能證明我們的身份，因為身份證是有受信任的公安機關頒發的。同樣的道理，當客戶端連接到 SSL 服務器的時候，其也要 SSL 服務器告訴客戶端一個類似於身份證的憑證文件，這個憑證就是 SSL 的證書。身份證上面有持有人的姓名、戶口地址、唯一的身份證 ID、頒發的公安局機關、身份的有效日期；類似的，SSL 證書裡面也有類似的信息，比如當前證書的通用名字（Common Name）、國家城市省份組織信息、聯繫人的郵箱、證書的指紋、頒發機構。下面以實際例子說明一下， 打開百度的網站，找到地址欄上面的鎖，點擊鎖，在彈出的窗體中點擊查看證書（View Certificates），其會彈出一個 SSL 證書，如下圖所示意。

enter image description here

（1）先點擊通用（General）頁面，在通用（General）頁面會顯示其證書的名字，證書的頒發機構（也就是後面即將要解釋的 CA），以及證書的有效日期。

enter image description here

（2）然後點擊詳細（Detail）頁面，其列出了當前 SSL 證書的主要信息。

類似於身份證的名字、戶口地址信息.

enter image description here

SSL 證書的指紋類似於身份證的 ID，其本質就是 SSL 證書內容的一個信息摘要（Message Digist）。

enter image description here

SSL 證書的頒發者（Issuer）類似於身份證裡面的頒發身份證的公安局信息。

enter image description here

enter image description here

在 SSL 證書的詳情（Detail）頁面還有其他的信息、簽名的算法、簽名的哈希算法、指紋算法、有效日期範圍等等，感興趣的讀者可以自行找一個證書點擊理解，如果有任何問題，可以在我的讀者圈留言。

（3）最後點擊證書路徑（Certification Path），我們會看到百度網站證書，總共有三個層級，這個就是證書的路徑，其表明了頒發的歸屬關係。

還是拿身份證為例子，比如，一個北京海淀區居民的身份證，其頒發機構是北京市海淀區公安分局頒發的，那北京海淀區公安分局頒發是誰授權其頒發身份證的權利的？ 當然是其上級單位，比如北京市公安局，而北京市公安局又是中國公安部最終給授權的，也就是根授權。

現在拿我們的百度證書路徑顯示的信息來進行類比，baidu.com 這張證書是 Symantec Class 3 Secure Server CA -G4 這個中級證書授權的，這個中級證書就相當於北京海定區公安分局或者北京市公安局，而 Symantec Class 3 Secure Server CA -G4 這個證書還沒有到頂，其又是 Versign 授權的，但是 Versign 到頂了，這個 Versign 就相當於中國公安部，其本質就是一個層級的授權結構。

enter image description here

對稱加密算法（Symmetric Encryption）是一種計算機加密技術，使用加密密鑰來偽裝信息，它的數據轉換使用了一個數學算法和一個私有密鑰，這導致無法從加密後的消息中推出原始消息。對稱加密是一種雙向算法，只要有相同的私鑰，通過數學算法就能把以前用一把私鑰加密的信息還原成最初的原始信息，對稱加密算法的最大特點就是加密數據和解密數據使用的是同一個秘鑰。

舉個簡單的例子，大家都喜歡看諜戰劇，諜戰劇裡面經常會看到某一方截獲了另外一方的密電，這個密電就是經過某一種方式加密過後的信息，那為什麼要加密呢？因為電波是朝四面八方擴散的，只要能夠接收電波，就能把電波里面附帶的信息記錄下來，如果不加密，特別是軍事情報，那豈不是太容易被截取並洩密了嗎？所以需要加密。加密的方式有多種多樣，舉個最簡單的加密方式，比如如果準備用英文單詞寫電報的話，就按照字母表的順序混淆一下，比如把 a 替換成 d，b 替換成 e，c 替換成 f 等，總之就是把當前的字母替換為後面第三位的字母，這種替換規則就是一個秘鑰。當接受方接收到這個信息的時候，因為預先知道這個秘鑰，所以，接到密文後，反向替換即可，即把密文中的 d，還原成 a，e 還原成 b，f 還原成 c。因為加密解密用的同一份秘鑰，加密和解密通過秘鑰是完全對稱的，所以叫做對稱加密。

目前比較通用和常見的對稱加密算法主要有下面的種類：

千言萬語抵不過一幅圖，下面是筆者從網上找了張經典的圖，大家一看圖就應該明白了什麼是對稱加密算法。

enter image description here

既然對稱加密算法這麼強大，那為什麼還要使用非對稱加密算法呢？那什麼又是非對稱加密算法呢？

因為對稱加密算法有一個最不安全的地方，就是秘鑰的分發；如何保證秘鑰能從 A 處共享給 B 的時候，特別是在複雜和萬能的互聯網上，如何保證在交換秘鑰的時候不被竊聽到？因為對於對稱加密算法，只要秘鑰被竊聽到了，其被這個秘鑰加密的任何密文幾乎不費吹灰之力就被破解出來了，那如何避免這種風險呢？這個時候非對稱加密算法就粉墨登場了。

非對稱加密算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey），公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。那為什麼這種機制就能很好的解決秘鑰傳輸的問題呢？ 舉個例子，假設有通信的雙方（A 和 B），需要交換一個秘密信息，A 會生成一個秘鑰對，公鑰 A 和私鑰 A；B 也會生成一個秘鑰對，公鑰 B 和私鑰 B，假設 A 和 B 都能把自己私鑰保護的滴水不漏，只要 A 和 B 兩個人自己知道自己各自的私鑰，其他任何人都不知道，就能保證信息交換的安全，交換的過程如下：

是不是整個通信就非常安全了？因為任何第三方即使在公鑰 A 和公鑰 B 相互交換的過程中知道到了公鑰 A 和公鑰 B，也沒有用，因為私鑰 A 和私鑰 B 沒有相互交換，只有各自自己知道，從而保證了通信雙方通信的安全。

目前 SSL/TLS 支持三種算法，但實際上只有 RSA 這一種被廣泛使用；DSA 已經被廢棄，而 ECDSA 在未來幾年內有望被廣泛使用。

（1）RSA

需要說明的是，RSA 算法是最常見的一種選擇，基本上所有的 SSL/TLS 部署都會支持 RSA 算法，但是，RSA 在 2048 位（最小位數）的密鑰下，比 ECDSA 密鑰在安全性上更弱並且性能更差。更糟的是，增加 RSA 密鑰長度是性能消耗的增加並不是線性的，如果你覺得 2048 位的加密強度不夠，需要使用更高的位數（比如 3072 位）的 RSA 密鑰時，在性能上就會有極大幅度的下降。

（2）DSA

DSA 算法現在被應用的比較少了：因為 DSA 的密鑰長度最大隻能到 1024 位（IE 瀏覽器也不支持更高強度），這個位數根本無法確保安全性，所以沒有人會在 SSL/TLS 實際應用中使用 DSA 算法，與所有人背道而馳的結果是讓你陷入兼容性問題中。

（3）ECDSA（橢圓曲線數字簽名算法）

ECDSA 算法是未來的選擇，256 位的 ECDSA 密鑰有 128 位用於安全加密上，相對而言，2048 位的 RSA 密鑰只有 112 位是真正用於安全加密的。不僅如此，在這個加密強度下，ECDSA 比 RSA 算法快 2 倍；如果是與 3072 位的 RSA 密鑰在相同加密強度下相比，ECDSA 性能要快 6 倍以上。

因為橢圓曲線（Elliptic Curve，EC）算法是最近才被加入到 TLS 的安全體系中，所以 ECDSA 的問題在於：不是所有用戶端都支持這種算法。新的瀏覽器都支持 ECDSA，但是一些老版本的瀏覽器是不支持這個算法的。你可以通過同時部署 RSA 和 ECDSA 的密鑰來解決對新老瀏覽器的兼容，但並不是所有服務程序都能提供這種配置方式，另外這種方案也需要額外的工作來同時維護兩套密鑰和證書。因此，就現狀而言，ECDSA 的最佳使用場景是用於部署追求最高性能的 TLS 服務系統。未來，隨著我們對安全的日益重視，ECDSA 也會變得越來越重要。

千言萬語抵不過一幅圖，下面是筆者從網上找了張經典的圖，大家一看圖就應該明白了什麼是非對稱加密算法。

enter image description here

電子商務認證授權機構（CA，Certificate Authority），也稱為電子商務認證中心，是負責發放和管理數字證書的權威機構，並作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。其就好比頒發身份證的公安局，當我們申請身份證的時候，我們必須要提供各種資料證明這個身份證是你的，比如你的戶口本、家庭成員信息，那麼 CA 也是類似，對於一些正規的商業的知名的 CA，當公司或者個人申請 SSL 證書的時候，CA 會驗證申請人的信息是否可信任。

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

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

如果用戶想得到一份屬於自己的證書，他應先向 CA 提出申請。在 CA 判明申請者的身份後，便為他分配一個公鑰，並且 CA 將該公鑰與申請者的身份信息綁在一起，併為之簽名，此後，便形成證書發給申請者。如果一個用戶想鑑別另一個證書的真偽，他就用 CA 的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認為是有效的。

下面的目前世界上最知名的8家 SSL 證書 CA 供應商。

簽發 SSL 證書的 CA 供應商之間的區別主要有：機構品牌、證書加密方式、保險額度、服務與質量、瀏覽器支持率等。當然，CA 機構也符合「越大越好」這個說法。

當然網上也有一些能申請免費 SSL 證書的 CA 供應商，比較知名的有：

上面介紹的免費 SSL 證書，要說最讓人放心的當屬 Let's Encrypt、騰訊雲和阿里雲的 DV SSL 證書，其他免費的 SSL 證書，建議大家謹慎使用，對於一些重要的網站還是建議直接購買 SSL 證書。

為了區分不同的用戶級別，服務端證書可以分成 DV、OV 和 EV 證書，他們之間具體有什麼區別，請參考雲棲社區的一篇博客《CA 和證書那些事》，分析的很專業。

如果需要在實際公共互聯網（Internet）部署的 SSL 服務器，強烈推薦到商業的知名的 CA 去申請 SSL 證書。

但是在一個企業的內部的私有網絡裡，比如，局域網（Intranet）內，其可能會有很多企業自己的基於 Web 的網站系統（比如工作流審批、考勤、辦公等）或者消息中間件服務器或者其他企業級應用系統，這些應用系統只暴露在局域網內，不會暴露在公有網絡中，但是又需要有 SSL 保護各個系統之間的通信，比如存儲企業所有應用系統或者個人信息的密碼的 PMP 服務器（Password Management Professional），在訪問和調用其 API 的時候，就一定要基於 HTTPS，因為密碼可是機密信息啊。

但是出於成本考慮或者保密性要求，我們沒有必要向第三方商業 CA 申請 SSL 證書，不但花錢，而且還要提供一些雜七雜八的企業證明信息，這個時候，就可以考慮在企業內部搭建一個私有的 CA，搭建已給自己的局域網（Intranet）的一個私有 CA。具體的搭建步驟，在後面的文章會有實戰的例子和文章，比如如何生成 CA 的根證書，CA 的中級代理證書，如何用中級 CA 代理證書來進行簽名 SSL 的證書請求，敬請拭目以待吧。

自簽名證書，就是自己給自己頒發證書，換句話就是說，證書的使用者和頒發者是同一個 SSL 服務器，自簽名證明一般用在開發或者測試環境，在正式的生產或者商用環境，建議大家生成證書請求，然後發送給第三方的 CA 或者自己搭建的企業內部的 CA 去簽名部署。下面就是用 JDK 自帶的 Keytool 為 www.51talkdocter.com 生成一個自簽名證書的命令。

假設我們在 Windows 操作系統上面，打開 cmd（在 Linux 操作系統上面打開 Shell），輸入下面的命令：

輸入上面的命令後，其會讓我們輸入描述證書的信息，比如國家、組織、城市、省份等，輸入對應的信息即可，如下圖說示意。

enter image description here

注意：因為上面一個命令同時生成了自簽名證書的公鑰和私鑰並存在在 KeyStore 文件中，所以需要一個保護這個 KeyStore 的密碼，比如當前的這個例子，為了簡單起見，我輸入的是“123456”，這對於測試環境和開發環境已經足夠，但是如果是正式的生成環境，建議用一個強度高的密碼進行保護。

我們可以通過下面的命令查看 keystore.jks（比如路徑在 c:\\keystore.jks）裡面生成的自簽名證書的詳細細節。

注意，最後的參數 -v 不能省略，其代表 Verbose，否則其就得不到詳細的信息，而且其會提示讓我們輸入密碼，密碼就是上面步驟提到的保護。

下面是其具體的輸出信息詳情。

enter image description here

從上圖的詳細情況來看，的的確確，證書的所有者（在圖中顯示的是 Owner）和證書的頒發者（在圖中顯示的是 Issuer）是一樣的，這就代表其是自簽名的證書。如果用瀏覽器訪問自簽名的證書的時候，瀏覽器會彈出一個警告的提示。

其實生成自簽名證書的方法很多，除了使用 JDK 外，後面提及到 OpenSSL、XCA、PowerShell、IIS 都自帶了生成自簽名證書的功能。如果你想進一步瞭解他們的使用或者配置方法，不僅僅侷限於自簽名，請繼續關注後續的系列文章內容。

證書籤名請求（CSR，Certificate Signing Request）就是一段經過編碼的字符文本，其會發送給 CA，CA 簽名之後，其就變成了一個 SSL 證書，所以發送給 CA 之前，其是一個 CSR 的文件，CA 簽名之後，其就變成了一張真正意義上的 SSL 證書，可以用於服務器的 SSL 配置了。

在理解證書籤名請求的時候，一定要記住，你生成證明簽名請求的私鑰一定不要發送給 CA，因為 CA 只需要你的 CSR 文件即可，不需要你提供生成證書籤名申請的私鑰，這個是初學者最容易犯的一個錯誤。

根據 PCKS #10 的規範，CSR 一般使用 ASN.1 的編碼標準對 CSR 文件進行編碼。CSR 文件中一般會包含下面的一些信息：

名稱解釋例子通用名 Common Name必須是你域的全名*.51talkdocter.com 或者mail.51talkdocter.com組織名 Organization組織的合法名稱，最好帶有下面類似的後綴， Inc、Corp or LLC51 talk Docter Inc.組織部門 Organizational Unit組織下面申請這個證書的部門比如 IT 部門城市 City/Locality公司所在的城市比如上海（Shanghai）省份或者州 State/County/Region公司所在的省份或者州比如California， 廣東省（Guangdong）國家 Country公司註冊地所在的國家，2位的 ISO碼，比如 cn、us中國的2位碼就是 cn，美國是us郵箱地址 Email address聯繫你組織的郵箱地址比如 [email protected]公鑰 Public Key生成的證書籤名請求 CSR 中裡面一定包含了公鑰，但是沒有私鑰生成證書請求的時候，由第三方工具自動生成的

使用 OpenSSL，下面的一條命令就能生成。

如果你還不會安裝和使用 OpenSSL，沒有關係，後面會有文章深入淺出的詳細介紹使用 OpenSSL 來生成和管理證書。

假設我們是一個 Java 程序員，則也可以藉助 JDK 自帶的 Keytool 生成證書請求，其一般經過兩個步驟：

（1）生成私鑰，並在生成 CSR 的過程中輸入 SSL 證書的相關描述信息，比如通用名稱、國家、城市、省份、組織、部門等：

其中，-validity 3650 參數代表證書的生存週期是 10 年。

enter image description here

（2）利用私鑰生成 CSR：

生成的證書請求文件，用文本編輯器打開，其就是類似於下面的樣子。

enter image description here

需要注意的是 CSR 和私鑰的長度決定了其是否能被破解的難易程度，截止 2018 年，私鑰長度小於 2048 位的都可以被認為是有潛在安全風險的，因為根據現有的計算機的計算能力，小於 2048 的私鑰在幾個月內就能根據公鑰成功碰撞私鑰，如果一旦私鑰被破解出來，初始化 SSL 連接其對稱加密的秘鑰就可能被破解者獲取，從而無法保證 SSL 在通信圖中的信息安全。建議在生成 CSR 的時候，使用的秘鑰的長度強烈推薦為 2048 位。

本章主要介紹了和 SSL 相關的幾個核心概念，比如什麼是 SSL 證書、對稱加密和非對稱加密、商業 CA 和私有 CA 的區別、證書籤名請求是什麼以及其需要注意的事項。

限於篇幅有限，不可能把所有的概念面面俱到，這可能要寫好幾本書了，所以只列出了這些對後續的閱讀和理解非常有幫助的核心概念。作為讀者的一個引子，如果你對其中的一部分感興趣的話，也可以繼續深挖下去。

限於作者水平，如果有任何疏漏之處，敬請在讀者圈留言，我將盡我最大的能力在讀者圈裡回答你的問題。最後，祝大家學習愉快。

工欲善其事必先利其器，在查看、生成、轉換、導入、導出等 SSL 證書的管理方面，OpenSSL 有著得天獨厚的功能是支撐。OpenSSL 採用 C 語言作為開發語言，這使得 OpenSSL 具有非常優秀的跨平臺性能；它支持 Linux、Windows、Mac、VMS 等多個平臺，這使得 OpenSSL 具有非常廣泛的適用性，如 Apache 使用它加密 HTTPS 協議，OpenSSH 使用它加密 SSH。

本節是後面一些文章的基礎，建議讀者按照本文列出的實戰步驟，動手自己安裝並執行，肯定會有意想不到的收穫。

enter image description here

OpenSSL 是一個穩定的、商用等級的、功能全面的、免費開源的，專為 SSL/TLS 而生一款工具，其命令功能主要分為下面三大類。

enter image description here

下面一些命令可能比較常用：

其也提供了下面的生成信息摘要的命令函數和工具：

其中不得不提的就是 MD（Message Digest）和 SHA，MD4 是 Rivest 於 1990 年設計的單向散列函數，能夠產生 128 比特的散列值，不過隨著 Dobbertin 提出尋找 MD4 散列的碰撞的方法，因此現在它已經不安全了。MD5 是也是由 Rivest 於 1991 年設計的單向散列函數，也能夠產生 128 位的散列值，不過 MD5 的強抗碰撞性已經被攻破，換句話就是說，現在已經能夠產生具備相同散列值的兩條不同的消息，因此 MD4/MD5 的算法都已經不安全了。

再來看看 SHA 相關的算法，SHA-1 是由 NIST（美國國家標準技術研究所）設計的一種能夠產生 160 比特的散列值的單向散列函數，1993 年被美國聯邦信息處理標準規格發佈的時候 SHA，1995 年又發佈了一個修訂版，稱之為 SHA-1，不過 SHA-1 的強抗碰撞性已於 2005 年被攻破。SHA224、SHA256、 SHA384、SHA512 也都是有 NIST 設計的單向散列函數，他們的散列值長度分別為 224 比特、256 比特、384 比特、512 比特，四種單向散列函數合起來稱為 SHA-2，SHA-2 目前還尚未被攻破。

那麼在實際應用中，是不是強度越高越好？筆者認為不一定，畢竟生成的信息摘要的位數越多，其需要的計算能力越多，需要存儲生成的信息摘要的空間要求越大，如果是一個自己的小型的、臨時的應用，MD4/MD5 生成的安全摘要已完全夠用，但是如果是需要暴露於公網，且牽涉到一些財產生命安全相關的領域，當然肯定是選用安全級別更高的 SHA-2 生成的信息摘要。

OpenSSL 不但有和管理生成 SSL 證書相關的命令，更令人驚豔的是其還是一個密碼學方面的專家工具箱，其提供了非常多的密碼學相關的工具函數，如下。

enter image description here

大家比較常見的就是 RC（是一種對稱加密，加密的密鑰流和明文一樣長，同樣的密鑰和同樣的長度能確定同一個密鑰流），DES（一種將 64 比特的明文加密成 64 比特的密文的對稱加密算法），AES（Advanced Encryption Standard，在密碼學中又稱 Rijndael 加密法，是美國聯邦政府採用的一種區塊加密標準），BASE64（一種把二進制加密成為 ASCII 字符），CBC（CBC 模式由 IBM 發明與 1976 年，在 CBC 模式中，每個明文塊先與前一個密文塊進行異或後，再進行加密）等算法。感興趣的讀者可以自行百度或者 Google，網上的資料比較多，這裡就不再贅述了。

如果讀者用的是 Linux 操作系統，恭喜你，一般的 Linux 操作系統都會自帶 OpenSSL 工具，你所需要確認的就是其當前是否安裝的是最新版本，如果你用的是 Windows 操作系統，也不用擔心，OpenSSL 也提供了 Windows 版本的安裝程序，本文就以 Windows 操作系統為例子，和大家分享一下如何安裝 OpenSSL。

下載地址詳見這裡。

enter image description here

OpenSSL 支持 32 位和 64 位，這個需要根據自己系統的實際情況選擇，這裡我下載的是 Win64 OpenSSL v1.1.0g 進行安裝。

enter image description here

下載完成之後就可以進行安裝了。

enter image description here

安裝完成後進行環境變量配置，例如 OpenSSL 安裝在 C:\\OpenSSL-Win64 目錄下，則將 C:\\OpenSSL-Win64\\bin; 複製到 path 中（注意：下圖為 Windows10 系統下環境變量配置的配圖）。

enter image description here

打開 cmd 命令窗口，輸入 openssl version，如果顯示版本號，那麼恭喜你安裝成功，否則安裝失敗。

enter image description here

因為在後面的章節，比如《如何用 OpenSSL 搭建企業內部 CA 認證中心的根證書？》、《如何用 OpenSSL 搭建 CA 認證中心的中級 CA 證書？》、《三種方法從 HTTPS 網站導出 SSL 證書鏈》等文章（但不侷限於這些文章）都能看到 OpenSSL 的高級用法的身影，所以本部分的 OpenSSL 實戰操作將只和大家分享一些基本的 OpenSSL 的操作技能，讓大家找到感覺，而不至於在學習後面的課程時，感到一頭霧水。請注意，本文的所有例子都在 Windows 操作系統上進行，對於非 Windows 操作系統，其操作命令大同小異。

有的時候，我們想知道當前安裝的 OpenSSL 版本、安裝的目錄等信息，此時，可以執行下面的命令：openssl version -a。

enter image description here

如上圖所示，其顯示當前的安裝版本是 1.1.0g，安裝的目錄是 “C:\\Program Files\\OpenSSL”。

當學習一門新技術時，很多人首先會想它有沒有提供一些 help，那 OpenSSL 有沒有為我們提供呢？ OpenSS 作為一個強大的工具庫，答案肯定是有。OpenSSL 為我們提供了 OpenSSL help 這個強大的命令，可以概覽 OpenSSL 的所有命令，我們只需要在 cmd 控制檯輸入 openssl help 即可：

enter image description here

使用 OpenSSL xxx -help 可以查看具體一條命令的用法以及它的參數（注意：xxx 為具體命令），如 OpenSSL md5 -help（下面的截圖只顯示了部分內容）。

enter image description here

通過 openssl help 命令，我們可以知道通過 genrsa 可以生成一個高強度的私鑰，如果直接在 openSSL 的控制檯輸入 genrsa，則其會默認生成一個 2048 位的私鑰。

enter image description here

當然，我們也可以指定一些參數，讓其輸入到指定的文件，比如事先已經創建了一個 c:\\openssldemo 的文件夾，然後在 OpenSSL 的環境下執行下面的命令：

enter image description here

則其會生成一個 fd.key 的私鑰，用記事本打開，其內容如下：

其是一個可以用文本編輯器打開的普通文本文件，其開頭的內容顯示其是基於 AES 方式進行加密的。中間的私鑰的內容是基於 BaseCode 64 編碼格式的字符串。

上面我們用 genrsa 生成了一個私鑰，因為 OpenSSL 也提供了一些密碼學的工具，我們可以藉助其提供的 RSA 的密碼工具，來查看其私鑰的相關的信息。

執行上面的命令後，其會把 fd.key 的具體信息全部列出來，比如模的信息、共有組件、私有組件等，具體信息如下：

絕對是研究 RSA 算法的一個非常得力的工具。

我們在配置網站的時候，可能需要為網站創建一個 SSL 的證書請求，那麼用 OpenSSL 應該如何做呢？其實很簡單，因為 OpenSSL 就有一個 req 的命令，專門用來創建證書請求。需要注意的是，在創建一個 SSL 的證書請求前，先要創建一個私鑰來，我們可以直接使用上面的私鑰，通過 -key 的參數 c:\\openSSLDemo\\fd.key 來指定，然後通過 -out 的參數指定其輸出的文件路徑。

中途需要輸入你的包含私鑰 c:\\openSSLDemo\\fd.key 的密碼，然後再需要你輸入證書的基本信息，比如國家、地區、城市、組織、通用名、郵箱地址等，比如下面我的申請。

證書請求生成後，可以通過下面的命令查看生成的證書請求。

其中，-text 表示已文本的方式查看，-in 後面需要知道待查看的證書的請求的路徑，-noout 表示不輸出其已經被編碼的證書文本本身，下面為命令執行結果的輸出。

如果你只是安裝一個 SSL/TLS 服務器，比如在 IIS 或者 Tomcat 上面部署一個 Web 站點，而且這個站點只是供你自己開發測試使用，這個時候，就沒有必要把證書請求發送給第三方的權威的商業 CA 去簽名我們的證書請求，最快最方便的方式就是自己簽署自己，從而生成一個自簽名的 SSL 證書。OpenSSL 已經為我們考慮好了，其命令如下：

其中，x509 -req 表示要進行 SSL 證書的自簽名了，-days 365 表示自簽名的證書的有效期限為 1 年，從剛剛算起；-signkey 表示用的是生成證書請求的私鑰，也就是自己給自己簽名；-in 表示證書請求的路徑，-out 表示生成的自簽名證書輸出的路徑。

運行上面的命令後，生成的 fd.crt 自簽名的證書如下：

enter image description here

證書生成後，我們需要測試或者查看證書，這個時候，就可以使用下面的類似命令了。

其中，-in 參數表示的是需要查看的證書的路徑，-noout 表示不輸出其已經被編碼的證書文本本身，命令的執行結果如下：

本篇文章首先闡述了 OpenSSL 工具的作用，其主要是用來管理 SSL 證書的，但是也提供了非常有用的密碼學工具箱，用於密碼學測試驗證。緊接著，和大家分享瞭如何安裝 OpenSSL，特別是在 Windows 操作系統上，並以 Windows 操作系統為平臺，在上面根據不同的假設場景，實戰演練了一把。

知易行難，如果讀者能夠仿照上面的實戰步驟，一一執行一下，我想不僅能夠加深印象，而且能夠對其基本的命令操作方式找到一種感覺，從而能夠舉一反三。限於筆者水平，如果有錯誤或者理解不當之處，請與我聯繫改正，最後祝大家學習愉快，收穫良多。