https介紹

Https概述與流程

HTTP

HTTP
超文本傳輸協(xié)議協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息壤巷，HTTP協(xié)議以明文方式發(fā)送內(nèi)容灾搏，不提供任何方式的數(shù)據(jù)加密缴淋，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報文趾唱，就可以直接讀懂其中的信息，因此腺晾，HTTP協(xié)議不適合傳輸一些敏感信息捆昏，比如：信用卡號、密碼等支付信息淌友。使用TCP端口為80煌恢。

HTTPS

為了解決HTTP協(xié)議的這一缺陷，網(wǎng)景公式設(shè)計了SSL(Secure Sockets
Layer-安全套接層)協(xié)議用于對Http協(xié)議傳輸?shù)臄?shù)據(jù)進行加密震庭，保證會話過程中的安全性瑰抵。使用TCP端口為
443。SSL依靠證書來驗證服務(wù)器的身份器联，并為瀏覽器和服務(wù)器之間的通信加密二汛。

HTTPS也稱作HTTP over TLS。TLS(Transport Layer
Security-傳輸層安全)協(xié)議的前身是SSL拨拓，TLS 1.0通常被標(biāo)示為SSL 3.1肴颊，TLS 1.1為SSL
3.2，TLS 1.2為SSL 3.3渣磷，TLS 1.3為SSL 3.4婿着。

SSL1.0 SSL2.0 SSL3.0 TLS1.0(SSL3.1) TLS1.1(SSL3.2) TLS1.2(SSL3.3) TLS1.3(SSL3.4)

紅色的表示不安全的，綠色的是安全的醋界。

層級 層名 常用協(xié)議
7 應(yīng)用層 HTTP/HTTPS竟宋、FTP、Socket形纺、Telnet丘侠、SSH、SMTP挡篓、POP3婉陷、DHCP、DNS官研、NFS秽澳、SNMP
6 表示層 XDR、LPP
5 會話層 SSL/TLS戏羽、LDAP/DAP担神、RPC
4 傳輸層 TCP、UDP
3 網(wǎng)絡(luò)層 IP始花、OSPF妄讯、ICMP孩锡、
2 數(shù)據(jù)鏈路層 以太網(wǎng)、令牌環(huán)亥贸、PPP躬窜、PPTP、L2TP炕置、ARP荣挨、ATMP
1 物理層 物理線路、光纖朴摊、無線電

客戶端執(zhí)行https請求時默垄，需要由TCP協(xié)議建立和釋放連接。這就涉及TCP協(xié)議的三次握手和四次揮手甚纲。

注意：我們可能會經(jīng)晨诙В看到“HTTP的三次握手”這個說法，其實這種說法不準(zhǔn)確介杆，HTTP是沒有什么三次握手的鹃操，這個其實指的就是TCP的三次握手。

HTTPS認(rèn)證流程

TCP連接建立好后这溅，對于HTTP而言组民，服務(wù)器就可以發(fā)數(shù)據(jù)給客戶端棒仍。但是對于HTTPS悲靴，它還要運行SSL/TLS協(xié)議，SSL/TLS協(xié)議分兩層莫其，第一層是記錄協(xié)議癞尚，主要用于傳輸數(shù)據(jù)的加密壓縮；第二層是握手協(xié)議乱陡，它建立在第一層協(xié)議之上浇揩，主要用于數(shù)據(jù)傳輸前的雙方身份認(rèn)證、協(xié)商加密算法憨颠、交換密鑰胳徽。

HTTPS驗證過程就是SSL握手協(xié)議的交互過程∷“HTTPS驗證”這個說法其實不準(zhǔn)確的养盗，應(yīng)該是“SSL驗證”，這兩種說法網(wǎng)上都能看到适篙。

https單相認(rèn)證

https://note.youdao.com/yws/public/resource/00a479b6b6d605908238c53b86e6df4b/xmlnote/WEB1ee02e17904898d5baaeaaec535487ad/7593F5312D3447248DFAEFECCE5A5ACB/6640

https雙向認(rèn)證之客戶端認(rèn)證

https://note.youdao.com/yws/public/resource/00a479b6b6d605908238c53b86e6df4b/xmlnote/WEB1ee02e17904898d5baaeaaec535487ad/CC09F989F8C243AAA0148D7C481D600C/6644

單向認(rèn)證

  1. 客戶端向指定域名的服務(wù)器發(fā)起https請求

請求內(nèi)容包括:

1）客戶端支持的SSL/TLS協(xié)議版本列表

2）支持的對稱加密算法列表

3）客戶端生成的隨機數(shù)A

  1. 服務(wù)器收到請求后往核，回應(yīng)客戶端，回應(yīng)的內(nèi)容主要有：

    1）SSL/TLS版本嚷节。服務(wù)器會在客戶端支持的協(xié)議和服務(wù)器自己支持的協(xié)議中聂儒，選擇雙方都支持的SSL/TLS的最高版本虎锚，作為雙方使用的SSL/TLS版本。如果客戶端的SSL/TLS版本服務(wù)器都不支持衩婚，則不允許訪問

2）與1類似窜护，選擇雙方都支持的最安全的加密算法。

3）從服務(wù)器密鑰庫中取出的證書

4）服務(wù)器端生成的隨機數(shù)B

  1. 客戶端回應(yīng)

客戶端收到后非春，檢查證書是否合法柄慰，主要檢查下面4點：

1、檢查證書是否過期

2税娜、檢查證書是否已經(jīng)被吊銷坐搔。

有CRL和OCSP兩種檢查方法。CRL即證書吊銷列表敬矩，證書的屬性里面會有一個CRL分發(fā)點屬性概行，如下圖所示（Microsoft
IT的證書），這個屬性會包含了一個url地址弧岳，證書的簽發(fā)機構(gòu)會將被吊銷的證書列表展現(xiàn)在這個url地址中凳忙；OCSP是在線證書狀態(tài)檢查協(xié)議，客戶端直接向證書簽發(fā)機構(gòu)發(fā)起查詢請求以確認(rèn)該證書是否有效禽炬。

image

3涧卵、證書是否可信。

客戶端會有一個信任庫腹尖，里面保存了該客戶端信任的CA（證書簽發(fā)機構(gòu)）的證書柳恐，如果收到的證書簽發(fā)機構(gòu)不在信任庫中，則客戶端會提示用戶證書不可信热幔。

若客戶端是瀏覽器乐设，各個瀏覽器都會內(nèi)置一些可信任的證書簽發(fā)機構(gòu)列表，在瀏覽器的設(shè)置中可以看到绎巨。

image

如果不在信任表中近尚，則瀏覽器會出現(xiàn)類似下面的警告頁面，提示你不安全场勤。（當(dāng)然戈锻，你可以選擇繼續(xù)訪問）

image

若客戶端是程序，例如Java中和媳，需要程序配置信任庫文件格遭，以判斷證書是否可信，如果沒設(shè)置窗价，則默認(rèn)使用jdk自帶的證書庫（jre\lib\security\cacerts,默認(rèn)密碼changeit）如庭。如果證書或簽發(fā)機構(gòu)的證書不在信任庫中，則認(rèn)為不安全，程序會報錯坪它。（你可以在程序中設(shè)置信任所有證書骤竹，不過這樣并不安全）。

4往毡、檢查收到的證書中的域名與請求的域名是否一致蒙揣。

若客戶端是程序，這一項可配置不檢查开瞭。若為瀏覽器懒震，則會出現(xiàn)警告，用戶也可以跳過嗤详。

證書驗證通過后个扰，客戶端使用特定的方法又生成一個隨機數(shù)c，這個隨機數(shù)有專門的名稱“pre-master
key”葱色。接著递宅，客戶端會用證書的公鑰對“pre-master key”加密，然后發(fā)給服務(wù)器苍狰。

  1. 服務(wù)器的最后回應(yīng)

    服務(wù)器使用密鑰庫中的私鑰解密后办龄，得到這個隨機數(shù)c。此時淋昭，服務(wù)端和客戶端都拿到了隨機數(shù)a俐填、b、c翔忽，雙方通過這3個隨機數(shù)使用相同的DH密鑰交換算法計算得到了相同的對稱加密的密鑰英融。這個密鑰就作為后續(xù)數(shù)據(jù)傳輸時對稱加密使用的密鑰。

    服務(wù)器回應(yīng)客戶端呀打，握手結(jié)束矢赁，可以采用對稱加密傳輸數(shù)據(jù)了。

這里注意幾點：

1贬丛、整個驗證過程，其實是為了安全地得到一個雙方約定的對稱加密密鑰给涕，當(dāng)然豺憔，過程中也涉及一些身份認(rèn)證過程。既然剛開始時够庙，客戶端已經(jīng)拿到了證書恭应，里面包含了非對稱加密的公鑰，為什么不直接使用非對稱加密方案呢耘眨，這是因為非對稱加密計算量大昼榛、比較耗時，而對稱加密耗時少剔难。

2胆屿、對稱加密的密鑰只在這次連接中斷前有效奥喻，從而保證數(shù)據(jù)傳輸安全。

3非迹、為什么要用到3個隨機數(shù)环鲤，1個不行嗎？這是因為客戶端和服務(wù)端都不能保證自己的隨機數(shù)是真正隨機生成的憎兽，這樣會導(dǎo)致數(shù)據(jù)傳輸使用的密鑰就不是隨機的冷离，時間長了，就很容易被破解纯命。如果使用客戶端隨機數(shù)西剥、服務(wù)端隨機數(shù)、pre-master
key隨機數(shù)這3個組合亿汞，就能十分接近隨機蔫耽。

4、什么是信任庫和密鑰庫留夜。信任庫前面已經(jīng)說了匙铡，它是用來存放客戶端信任的CA的證書。在程序交互中碍粥，需要確保你訪問的服務(wù)器的證書在你的信任庫里面鳖眼。密鑰庫是用來存放服務(wù)器的私鑰和證書。

5嚼摩、中間人攻擊問題钦讳。前面過程說明中，有一點枕面，客戶端是驗證有問題的時候愿卒，是可以選擇繼續(xù)的。對瀏覽器而言潮秘，用戶可以選擇繼續(xù)訪問琼开；對程序而言，有些系統(tǒng)為了處理簡單枕荞，會選擇信任所有證書柜候，這樣就給中間人攻擊提供了漏洞。

中間人攻擊時躏精，它想辦法攔截到客戶端與服務(wù)器之間的通信渣刷。在客戶端向服務(wù)器發(fā)信息時，中間人首先偽裝成客戶端矗烛，向真正的服務(wù)器發(fā)消息辅柴，獲得真正的證書，接著偽裝成服務(wù)器將自己的偽證書發(fā)給客戶端。服務(wù)器向客戶端發(fā)消息時碌嘀，中間人偽裝成客戶端涣旨，接收消息，然后再偽裝成服務(wù)器向客戶端發(fā)消息筏餐。最后驗證過程完成后开泽，客戶端的真實對稱密鑰被中間人拿到，而真正的服務(wù)器拿到的是中間人提供的偽密鑰魁瞪。后續(xù)數(shù)據(jù)傳輸過程中的數(shù)據(jù)就會被中間人竊取穆律。

雙向認(rèn)證

單向驗證過程中，客戶端會驗證自己訪問的服務(wù)器导俘，服務(wù)器對來訪的客戶端身份不做任何限制峦耘。如果服務(wù)器需要限制客戶端的身份，則可以選擇開啟服務(wù)端驗證旅薄，這就是雙向驗證辅髓。從這個過程中我們發(fā)現(xiàn)，使用單向驗證還是雙向驗證少梁，是服務(wù)器決定的洛口。

一般而言，我們的服務(wù)器都是對所有客戶端開放的凯沪，所以服務(wù)器默認(rèn)都是使用單向驗證第焰。如果你使用的是Tomcat服務(wù)器，在配置文件server.xml中妨马，配置Connector節(jié)點的clientAuth屬性即可挺举。若為true，則使用雙向驗證烘跺，若為false湘纵，則使用單向驗證。如果你的服務(wù)滤淳，只允許特定的客戶端訪問梧喷，那就需要使用雙向驗證了。

雙向驗證基本過程與單向驗證相同娇钱，不同在于：

1）第二步服務(wù)器第一次回應(yīng)客戶端的消息中伤柄，會要求客戶端提供“客戶端的證書”

2）第三步客戶端驗證完服務(wù)器證書后的回應(yīng)內(nèi)容中，會增加兩個信息：

1文搂、客戶端的證書

2、客戶端證書驗證消息（CertificateVerify
message）：客戶端將之前所有收到的和發(fā)送的消息組合起來秤朗，并用hash算法得到一個hash值煤蹭，然后用客戶端密鑰庫的私鑰對這個hash進行簽名，這個簽名就是CertificateVerify
message

3）服務(wù)器收到客戶端證書后：

a）確認(rèn)這個證書是否在自己的信任庫中（當(dāng)然也會校驗是否過期等信息），如果驗證不通過則會拒絕連接硝皂；

b）用客戶端證書中的公鑰去驗證收到的證書驗證消息中的簽名常挚。這一步的作用是為了確認(rèn)證書確實是客戶端的。

所以稽物，在雙向驗證中奄毡，客戶端需要用到密鑰庫，保存自己的私鑰和證書贝或，并且證書需要提前發(fā)給服務(wù)器吼过，由服務(wù)器放到它的信任庫中。

總結(jié)

1咪奖、單向驗證中盗忱，如果是你客戶端，你需要拿到服務(wù)器的證書羊赵，并放到你的信任庫中趟佃；如果是服務(wù)端，你要生成私鑰和證書昧捷，并將這兩個放到你的密鑰庫中闲昭，并且將證書發(fā)給所有客戶端。

2靡挥、雙向驗證中序矩，如果你是客戶端，你要生成客戶端的私鑰和證書芹血，將它們放到密鑰庫中贮泞，并將證書發(fā)給服務(wù)端，同時幔烛，在信任庫中導(dǎo)入服務(wù)端的證書啃擦。如果你是服務(wù)端，除了在密鑰庫中保存服務(wù)器的私鑰和證書饿悬，還要在信任庫中導(dǎo)入客戶端的證書令蛉。

3、再次強調(diào)狡恬，使用單向驗證還是雙向驗證珠叔，是服務(wù)器決定的。

4弟劲、https的驗證過程祷安，不管是單向還是雙向，只有四步兔乞，圖上畫的步驟只是為了便于理解汇鞭。很多關(guān)于https驗證過程的文章中凉唐，寫了來來回回七八上十步。要真是這樣霍骄，訪問一個https地址台囱，時間全花在了交互上了。

https雙向認(rèn)證與openssl

證書相關(guān)概念

CA(Certificate
Authority)：被稱為證書授權(quán)中心是數(shù)字證書發(fā)放和管理的機構(gòu)读整。簽發(fā)主流機構(gòu)：Symantec簿训、Thawte、GeoTrust米间、GlobalSign等强品。

根證書：CA證書授權(quán)中心給自己頒發(fā)的證書,
是信任鏈的起始點。安裝根證書意味著對這個CA認(rèn)證中心的信任车伞。權(quán)威CA機構(gòu)的根證書內(nèi)置于瀏覽器中择懂。

簽發(fā)證書的過程：

  1. 撰寫證書元數(shù)據(jù)：包括 簽發(fā)人(Issuer)、地址另玖、簽發(fā)時間困曙、有效期
    等，還包括證書持有者(Owner)基本信息谦去，比如 DN(DNS
    Name慷丽，即證書生效的域名)    、 Owner 公鑰 等信息

  2. 使用通用的 Hash 算法（如SHA-256）對證書元數(shù)據(jù)計算生成 數(shù)字摘要

  3. 使用 Issuer
    的私鑰對該數(shù)字摘要進行加密鳄哭，生成一個加密的數(shù)字摘要要糊，也就是Issuer的
    數(shù)字簽名

  4. 將數(shù)字簽名附加到數(shù)字證書上，變成一個 簽過名的數(shù)字證書

  5. 將簽過名的數(shù)字證書與 Issuer
    的公鑰    妆丘，一同發(fā)給證書使用者（注意锄俄，將公鑰主動發(fā)給使用者是一個形象的說法，只是為了表達使用者最終獲取到了
    Issuer 的公鑰）

驗證證書的過程：

  1. 證書使用者獲通過某種途徑（如瀏覽器訪問）獲取到該數(shù)字證書勺拣，解壓后分別獲得
    證書元數(shù)據(jù) 和 數(shù)字簽名

  2. 使用同樣的Hash算法計算證書元數(shù)據(jù)的 數(shù)字摘要

  3. 使用 Issuer 的公鑰 對數(shù)字簽名進行解密奶赠，得到 解密后的數(shù)字摘要

  4. 對比 2 和 3 兩個步驟得到的數(shù)字摘要值，如果相同药有，則說明這個數(shù)字證書確實是被
    Issuer 驗證過合法證書毅戈，證書中的信息（最主要的是 Owner 的公鑰）是可信的

證書鏈：http://www.reibang.com/p/fcd0572c4765

客戶端驗證服務(wù)器證書

客戶端驗證服務(wù)器證書

Openssl ：目前最流行的 SSL
密碼庫工具，其提供了一個通用愤惰、健壯苇经、功能完備的工具套件，用以支持SSL/TLS
協(xié)議的實現(xiàn)宦言。

X.509：是被廣泛使用的數(shù)字證書標(biāo)準(zhǔn)扇单，是用于標(biāo)志通訊各方身份信息的一系列數(shù)據(jù)。

X.509證書包含三個文件：key(私鑰)奠旺，csr(生成數(shù)字證書請求文件)令花，cer/crt(是用于存放證書的簽名文件阻桅，以二進制形式存放凉倚，不含私鑰)兼都。

生成數(shù)字證書

我們需要 自簽根證書、服務(wù)端證書稽寒、服務(wù)端私鑰扮碧、客戶端證書。

注意：Openssl使用1.0.2版本杏糙，否則生成請求文件會報錯慎王。

  1. 創(chuàng)建根證私鑰

OpenSSL>genrsa -out D:\F\two-way-verification\root-key.key 1024

說明：生成rsa私鑰，1024位長度宏侍，輸出到root-key.key赖淤。

  1. 創(chuàng)建根證書請求文件

OpenSSL> req -new -out D:\F\two-way-verification\root-req.csr -key
D:\F\two-way-verification\root-key.key

說明：會讓填寫信息,其中國家,省市,公司等需要和后面的證書保持一致.后面challenge
password的地方直接回車就好。

  1. 生成自簽根證書

OpenSSL> x509 -req -in D:\F\two-way-verification\root-req.csr -out
D:\F\two-way-verification\root-cert.cer -signkey
D:\F\two-way-verification\root-key.key -CAcreateserial -days 3650

  1. 生成服務(wù)端私鑰

OpenSSL> genrsa -out D:\F\two-way-verification\server-key.key 1024

  1. 生成服務(wù)端請求文件

OpenSSL>req -new -out D:\F\two-way-verification\server-req.csr -key
D:\F\two-way-verification\server-key.key

說明：國家省市公司和2)保持一致, Common Name 要特別注意,
要用你服務(wù)器的域名,我們測試用wangting.com

  1. 生成服務(wù)端證書（root-cert.cer谅河，root-key.key咱旱，server-key.key，server-req.csr
    這4個文件來生成服務(wù)端證書）

OpenSSL> x509 -req -in D:\F\two-way-verification\server-req.csr -out
D:\F\two-way-verification\server-cert.cer -signkey
D:\F\two-way-verification\server-key.key -CA
D:\F\two-way-verification\root-cert.cer -CAkey
D:\F\two-way-verification\root-key.key -CAcreateserial -days 3650

  1. 生成客戶端key

OpenSSL> genrsa -out D:\F\two-way-verification\client-key.key 1024

  1. 生成客戶端請求文件

OpenSSL> req -new -out D:\F\two-way-verification\client-req.csr -key
D:\F\two-way-verification\client-key.key

生成客戶端證書（root證書绷耍，rootkey吐限，client-key.key，client-req.csr這4個生成文件生成客戶端證書）

OpenSSL> x509 -req -in D:\F\two-way-verification\client-req.csr -out
D:\F\two-way-verification\client-cert.cer -signkey
D:\F\two-way-verification\client-key.key -CA
D:\F\two-way-verification\root-cert.cer -CAkey
D:\F\two-way-verification\root-key.key -CAcreateserial -days 3650

  1. 生成客戶端p12格式根證書(密碼設(shè)置123456)

OpenSSL> pkcs12 -export -clcerts -in
D:\F\two-way-verification\client-cert.cer -inkey
D:\F\two-way-verification\client-key.key -out
D:\F\two-way-verification\client.p12

為什么必須轉(zhuǎn)p12褂始，因為步驟9生成的證書導(dǎo)入不了瀏覽器客戶端诸典。

備注：參數(shù)名稱和意義

genrsa 產(chǎn)生RSA密鑰命令

req 產(chǎn)生證書簽發(fā)申請命令

x509 簽發(fā)X.509格式證書命令

pkcs12 PKCS#12編碼格式證書命令。

-in 表示輸入文件

-out 表示輸出文件

-req 表示證書輸入請求崎苗。

-export 表示導(dǎo)出證書

-inkey 表示輸入私鑰文件

-days 表示有效天數(shù)

-CAcreateserial 表示創(chuàng)建CA證書序列號

-CAkey 表示CA證書私鑰

-CA 表示CA證書

-signkey 表示自簽名私鑰

-new 表示新請求

-clcerts 表示僅導(dǎo)出客戶證書狐粱。

配置nginx服務(wù)

注意事項：1. nginx安裝包路徑中不能有中文，否則啟動不了

  1. 配置https的證書路徑時注意要使用/胆数，不能使用\肌蜻。

重定向http請求

server {

listen 80;

server_name 127.0.0.1;

rewrite ^(.*)https://host$1; # 強制轉(zhuǎn)https

}

創(chuàng)建監(jiān)聽443端口服務(wù)

server {

listen 443 ssl;

server_name wangting.com;

ssl_certificate D:/two-way-verification/server-cert.cer; #server公鑰證書

ssl_certificate_key D:/two-way-verification/server-key.key; #server私鑰

ssl_client_certificate D:/two-way-verification/root-cert.cer;

客戶端證書的CA證書了(即根證書)，代表此CA簽發(fā)的證書都是可信的幅慌。 使用 CA

證書來驗證請求帶的客戶端證書是否是該 CA 簽發(fā)的

ssl_verify_client off; #啟用客戶端證書審核

ssl_session_cache shared:SSL:1m; #設(shè)置儲存SSL會話的緩存類型和大小

ssl_session_timeout 5m; #設(shè)置客戶端能夠反復(fù)使用儲存在緩存中的會話參數(shù)時間

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #指定要使用的SSL協(xié)議

location / {

root D:/two-way-verification;

index index.html;

}

}

配置Host域名解析

C:\Windows\System32\drivers\etc\hosts

安裝客戶端證書

將client.p12進行安裝

備注：不同的客戶端證書通過Common Name 和 Email Address區(qū)分

image

注意: 為什么不安裝client-cert.cer證書

因為client-cert.cer證書中只有公鑰信息宋欺，雙向認(rèn)證瀏覽器安裝的客戶端證書中需要使用到私鑰信息。

https單向認(rèn)證與keytool

單向認(rèn)證

注釋掉

ssl_verify_client on; #啟用客戶端證書審核

Keytool簡介

keytool 是個Java提供的密鑰和證書管理工具胰伍。

keytool 將密鑰和證書儲存在一個稱為keystore的密鑰倉庫中

Keytool生成私鑰和證書

  1. 創(chuàng)建keystore秘鑰庫

keytool -genkey -v -alias wangting -keyalg RSA -validity 3650 -keystore
D:/one-way-verification/wangting.keystore

  1. 創(chuàng)建證書

keytool -export -alias wangting -keystore
D:/one-way-verification/wangting.keystore -storepass 123456 -rfc -file
D:/one-way-verification/wangting.cer

備注：參數(shù)名稱和意義

-keyalg 使用加密的算法齿诞，這里是RSA

-keypass 私有密鑰的密碼，這里設(shè)置為 123456

-keystore 密鑰庫

-validity 該密鑰的有效期為 365天 (默認(rèn)為90天)

-keysize 指定密鑰長度

-alias 證書別名

-storepass 指定密鑰庫的密碼

-export 將別名指定的證書導(dǎo)出到文件

-rfc 表示以base64輸出文件骂租，否則以二進制輸出

  1. 獲取秘鑰

keytool不提供命令導(dǎo)出私鑰祷杈，所以需要使用程序?qū)С鰇ey

image

配置nginx

更換nginx.conf中的私鑰和證書，域名如有變化需要更改

配置Host

C:\Windows\System32\drivers\etc\hosts

tomcat配置https

使用openssl生成的私鑰和證書

  1. 根據(jù)雙向認(rèn)證時生成的服務(wù)端證書和私鑰生成PKCS#12的證書文件：

    pkcs12 -export -clcerts -in D:\two-way-verification\server-cert.cer -inkey
    D:\two-way-verification\server-key.key -out
    D:\two-way-verification\server.p12

  2. 將server.p12文件轉(zhuǎn)為keystore：

    keytool -importkeystore -v -srckeystore D:/two-way-verification/server.p12
    -srcstoretype pkcs12 -srcstorepass 123456(p12剛輸入的密碼) -destkeystore
    D:/two-way-verification/server.keystore -deststoretype jks -deststorepass
    123456(keystore密鑰庫的密碼)

    注意：(標(biāo)黃的兩個密碼需要一致渗饮，不一致tomcat啟動時會報錯但汞。)

  3. 配置tomcat的server.xml

    image

  4. 啟動tomcat宿刮， 訪問https://wangting.com:8443/

  5. 在瀏覽器中配置證書

使用keytool生成keystore

  1. 使用單向認(rèn)證時生成的密鑰庫wangting.keystore，以及證書wangting.cer

  2. 配置tomcat的server.xml

    image

  3. 啟動tomcat私蕾， 訪問https://yada:8443/

  4. 在瀏覽器中配置證書

生成帶SAN的證書

問題：在之前的案例中我們發(fā)現(xiàn)及時瀏覽器安裝了證書僵缺，在谷歌瀏覽器中依然會警告

image

原因：Chrome 58 及以上版本只會使用 subjectAlternativeName 擴展程序（而不是
commonName）來匹配域名和網(wǎng)站證書。因此會報錯：NET::ERR_CERT_COMMON_NAME_INVALID
踩叭。

修改openssl配置文件

首先需要修改openssl.cnf（該文件在bin文件中）磕潮，有的bin文件中沒有openssl.cnf,
但是有openssl.cnf，將后綴名改一下就可以了容贝。

確保req下存在以下2行（默認(rèn)第一行是有的自脯，第2行被注釋了）

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req

確保req_distinguished_name下沒有 0.xxx 的標(biāo)簽，有的話把0.xxx的0. 去掉

新增最后一行內(nèi)容 subjectAltName = @alt_names（前2行默認(rèn)存在）

[ v3_req ]

Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

新增 alt_names,注意括號前后的空格斤富，DNS.x 的數(shù)量可以自己加

[ alt_names ]

DNS.1 = wangting.com

DNS.2 = yuxinditie.com

根據(jù)配置文件生成證書

1)生成私鑰

genrsa -out server.key 2048

  1. 生成csr文件

req -new -key server.key -out server.csr -config openssl.cnf

  1. 生成ca.key并自簽署

req -new -x509 -days 3650 -keyout ca.key -out ca.crt -config openssl.cnf

4)用生成的CA的證書為剛才生成的server.csr文件簽名

ca -in server.csr -out server.crt -cert ca.crt -keyfile ca.key -extensions
v3_req -config openssl.cnf

配置nginx服務(wù)

同上

配置Host域名解析

同上

使用程序訪問https網(wǎng)站

image

可以看到執(zhí)行完這段代碼膏潮，程序會報如下錯誤：

image

原因：驗證服務(wù)器證書時出錯，程序啟動后满力，java虛擬機會查看jvm信任的證書列表焕参，發(fā)現(xiàn)沒有信任服務(wù)器的證書。

解決方案: 將服務(wù)器證書導(dǎo)入到j(luò)dk脚囊。

keytool -import -v -trustcacerts -alias wang-ca -file D:/certWithSAN/ca.crt
-storepass changeit -keystore
D:/D/Installed/Java/jdk1.8.0_131/jre/lib/security/cacerts

重新運行程序龟糕，成功。

--查看jvm信任的證書列表

keytool -list -keystore
“D:/D/Installed/Java/jdk1.8.0_131/jre/lib/security/cacerts” -storepass changeit

--刪除證書

keytool -delete -alias wang2 -keystore
“D:/D/Installed/Java/jdk1.8.0_131/jre/lib/security/cacerts” -storepass changeit

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末悔耘，一起剝皮案震驚了整個濱河市讲岁，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌衬以，老刑警劉巖缓艳，帶你破解...
    沈念sama閱讀 216,591評論 6贊 501
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異看峻，居然都是意外死亡阶淘，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,448評論 3贊 392
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門互妓，熙熙樓的掌柜王于貴愁眉苦臉地迎上來溪窒，“玉大人，你說我怎么就攤上這事冯勉〕喊觯” “怎么了？”我有些...
    開封第一講書人閱讀 162,823評論 0贊 353
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵灼狰，是天一觀的道長宛瞄。 經(jīng)常有香客問我，道長交胚，這世上最難降的妖魔是什么份汗？ 我笑而不...
    開封第一講書人閱讀 58,204評論 1贊 292
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任盈电，我火速辦了婚禮，結(jié)果婚禮上杯活，老公的妹妹穿的比我還像新娘匆帚。我一直安慰自己，他們只是感情好轩猩，可當(dāng)我...
    茶點故事閱讀 67,228評論 6贊 388
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布卷扮。 她就那樣靜靜地躺著，像睡著了一般均践。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上摩幔，一...
    開封第一講書人閱讀 51,190評論 1贊 299
  • 城市分裂傳說
    那天彤委，我揣著相機與錄音，去河邊找鬼或衡。 笑死焦影，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的封断。 我是一名探鬼主播斯辰，決...
    沈念sama閱讀 40,078評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼太示！你這毒婦竟也來了毒姨？” 一聲冷哼從身側(cè)響起着憨，我...
    開封第一講書人閱讀 38,923評論 0贊 274
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎闸氮，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體教沾，經(jīng)...
    沈念sama閱讀 45,334評論 1贊 310
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡蒲跨，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,550評論 2贊 333
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了授翻。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片或悲。...
    茶點故事閱讀 39,727評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖堪唐，靈堂內(nèi)的尸體忽然破棺而出巡语，到底是詐尸還是另有隱情，我是刑警寧澤羔杨，帶...
    沈念sama閱讀 35,428評論 5贊 343
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布捌臊，位于F島的核電站，受9級特大地震影響兜材，放射性物質(zhì)發(fā)生泄漏理澎。R本人自食惡果不足惜逞力，卻給世界環(huán)境...
    茶點故事閱讀 41,022評論 3贊 326
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望糠爬。 院中可真熱鬧寇荧，春花似錦、人聲如沸执隧。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,672評論 0贊 22
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽镀琉。三九已至峦嗤，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間屋摔，已是汗流浹背烁设。 一陣腳步聲響...
    開封第一講書人閱讀 32,826評論 1贊 269
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留钓试，地道東北人装黑。 一個月前我還...
    沈念sama閱讀 47,734評論 2贊 368
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像弓熏，于是被迫代替她去往敵國和親恋谭。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,619評論 2贊 354