摘要：數(shù)字簽名數(shù)字簽名就是非對(duì)稱加密摘要算法，其目的不是為了加密，而是用來防止他人篡改數(shù)據(jù)。認(rèn)證是通過證書來達(dá)到的，而密碼交換是通過證書里面的非對(duì)稱加密算法公私鑰來實(shí)現(xiàn)的。

每次配置HTTPS或者SSL時(shí)，都需要指定一些cacert，cert，key之類的東西，他們的具體作用是什么呢？為什么配置了他們之后通信就安全了呢？怎么用openssl命令來生成它們呢？程序中應(yīng)該如何使用這些文件呢？

本篇以TLS 1.2作為參考，只介紹原理，不深入算法的細(xì)節(jié)

SSL(Secure Sockets Layer)和TLS(Transport Layer Security)的關(guān)系就像windows XP和windows 7的關(guān)系，升級(jí)后改了個(gè)名字而已。下面這張表格列出了它們的歷史：

最初的SSL只支持TCP，不過現(xiàn)在已經(jīng)可以支持UDP了，請(qǐng)參考Datagram Transport Layer Security Version 1.2

HTTPS=HTTP+TLS，其它的協(xié)議也類似，如FTPS=FTP+TLS。

注意：SSH和SSL/TLS是兩個(gè)不同的協(xié)議，SSH并不依賴于SSL/TLS

在正式開始介紹TLS之前，先澄清一些跟加密相關(guān)的概念：

對(duì)稱加密

這是我們加密文件常用的方式，加密的時(shí)候輸入一個(gè)密碼，解密的時(shí)候也用這個(gè)密碼，加密和解密都用同一個(gè)密碼，所以叫對(duì)稱加密。常見的算法有AES、3DES。

非對(duì)稱加密

非對(duì)稱加密是一個(gè)很神奇的東西，它有兩個(gè)不一樣的密碼，一個(gè)叫私鑰，另一個(gè)叫公鑰，用其中一個(gè)加密的數(shù)據(jù)只能用另一個(gè)密碼解開，用自己的都解不了，也就是說用公鑰加密的數(shù)據(jù)只能由私鑰解開，反之亦然。

私鑰一般自己保存，而公鑰是公開的，同等加密強(qiáng)度下，非對(duì)稱加密算法的速度比不上對(duì)稱加密算法的速度，所以非對(duì)稱加密一般用于數(shù)字簽名和密碼（對(duì)稱加密算法的密碼）的交換。常見的算法有RSA、DSA、ECC。

摘要算法

摘要算法不是用來加密的，其輸出長度固定，相當(dāng)于計(jì)算數(shù)據(jù)的指紋，主要用來做數(shù)據(jù)校驗(yàn)，驗(yàn)證數(shù)據(jù)的完整性和正確性。常見的算法有CRC、MD5、SHA1、SHA256。

數(shù)字簽名

數(shù)字簽名就是“非對(duì)稱加密+摘要算法”，其目的不是為了加密，而是用來防止他人篡改數(shù)據(jù)。

其核心思想是：比如A要給B發(fā)送數(shù)據(jù)，A先用摘要算法得到數(shù)據(jù)的指紋，然后用A的私鑰加密指紋，加密后的指紋就是A的簽名，B收到數(shù)據(jù)和A的簽名后，也用同樣的摘要算法計(jì)算指紋，然后用A公開的公鑰解密簽名，比較兩個(gè)指紋，如果相同，說明數(shù)據(jù)沒有被篡改，確實(shí)是A發(fā)過來的數(shù)據(jù)。假設(shè)C想改A發(fā)給B的數(shù)據(jù)來欺騙B，因?yàn)榇鄹臄?shù)據(jù)后指紋會(huì)變，要想跟A的簽名里面的指紋一致，就得改簽名，但由于沒有A的私鑰，所以改不了，如果C用自己的私鑰生成一個(gè)新的簽名，B收到數(shù)據(jù)后用A的公鑰根本就解不開。

TLS主要包含兩部分協(xié)議，一部分是Record Protocol，描述了數(shù)據(jù)的格式，另一部分是Handshaking Protocols，描述了握手過程，本篇中只介紹握手過程，不介紹具體的通信數(shù)據(jù)格式。

握手的目的有兩個(gè)，一個(gè)是保證通信的雙方都是自己期待的對(duì)方，任何一方都不可能被冒充，另一個(gè)是交換加密密碼，使得只有通信的雙方知道這個(gè)密碼，而別人不知道。前一個(gè)就是我們常說的認(rèn)證，而后一個(gè)就是密碼交換。認(rèn)證是通過證書來達(dá)到的，而密碼交換是通過證書里面的非對(duì)稱加密算法（公私鑰）來實(shí)現(xiàn)的。

先看握手的交互圖：

+--------+                                      +--------+
|        |   1. ClientHello                     |        |
|        |------------------------------------->|        |
|        |                                      |        |
|        |   2. ServerHello                     |        |
|        |   3. Certificate                     |        |
|        |   4. ServerKeyExchange (optional)    |        |
|        |   5. CertificateRequest (optional)   |        |
|        |   6. ServerHelloDone                 |        |
|        |<------------------------------------ |        |
| Client |                                      | Server |
|        |   7. Certificate (optional)          |        |
|        |   8. ClientKeyExchange               |        |
|        |   9. CertificateVerify (optional)    |        |
|        |  10. Finished                        |        |
|        |------------------------------------> |        |
|        |                                      |        |
|        |  11. Finished                        |        |
|        |<------------------------------------ |        |
+--------+                                      +--------+

注意： 下面解釋過程中用到的具體協(xié)議版本、算法和值都是示例，實(shí)際中可能不是這些

ClientHello

client->server: 
hello，咱建立個(gè)連接唄，我這邊的支持的最高版本是TLS1.1，
支持的密碼套件（cipher suite）有“TLS_RSA_WITH_AES_128_CBC_SHA”和“TLS_RSA_WITH_AES_256_CBC_SHA256”，
支持的壓縮算法有DEFLATE，我這邊生成的隨機(jī)串是abc123456。

這里有幾點(diǎn)需要解釋一下：

客戶端會(huì)把自己最喜歡的密碼套件放在最前面，這樣服務(wù)器端就會(huì)根據(jù)客戶端的要求優(yōu)先選擇排在前面的算法套件

密碼套件就是一個(gè)密碼算法三件套，里面包含了一個(gè)非對(duì)稱加密算法，一個(gè)對(duì)稱加密算法，以及一個(gè)數(shù)據(jù)摘要算法。以TLS_RSA_WITH_AES_128_CBC_SHA為例，RSA是非對(duì)稱加密算法，表示后面用到的證書里面的公鑰用的是RSA算法，通信的過程中需要簽名的地方也用這個(gè)算法，并且密碼（key）的交換過程也使用這個(gè)算法；AES_128_CBC是對(duì)稱加密算法，用來加密握手后傳輸?shù)臄?shù)據(jù)，其密碼由RSA負(fù)責(zé)協(xié)商生成；SHA是數(shù)據(jù)摘要算法，表示后面交換的證書里簽名
用到的摘要算法是sha1，并且后續(xù)通信過程中需要用到數(shù)據(jù)校驗(yàn)的地方也是用的這個(gè)算法。在Record Protocol協(xié)議中，摘要算法是必須的，即數(shù)據(jù)包都需要有校驗(yàn)碼，而簽名是可選的。

ClientHello里面還可以包含session id，即表示重用前面session里的一些內(nèi)容，比如已經(jīng)協(xié)商好的算法套件等，服務(wù)器收到session id后會(huì)去內(nèi)存里面找，如果這是一個(gè)合法的session id，那么它就可以選擇重用前面的session，這樣可以省去很多握手的過程。為了簡化討論，這里不介紹session重用的問題。

ServerHello

server收到client的hello消息后，就在自己加載的證書中去找一個(gè)和客戶支持的算法套件相匹配的證書，并且挑選一個(gè)自己也支持的對(duì)稱加密算法（證書里面只有非對(duì)稱加密和摘要算法，不包含對(duì)稱加密算法）。如果出現(xiàn)下面幾種情況，握手失?。?/p>

客戶端支持的TLS版本太低，比如server要求最低版本為1.2，而客戶端支持的最高版本是1.1

根據(jù)客戶端所支持的密碼套件，找不到相應(yīng)要求的證書

無法就支持的對(duì)稱加密算法達(dá)成一致

如果一切都OK，那么服務(wù)器端將返回ServerHello：

server->client: 
hello，沒問題，我們就使用TLS1.1吧，
算法采用“TLS_RSA_WITH_AES_256_CBC_SHA256”，這個(gè)加密強(qiáng)度更高更安全，
壓縮就算了，我這邊不支持，我這邊生成的隨機(jī)數(shù)是654321def。

如果server支持session重用的話，這里還會(huì)返回session id

Certificate

服務(wù)器在發(fā)送完ServerHello之后緊接著發(fā)送Certificate消息，里面包含自己的證書。

當(dāng)然這步在有些情況下可以忽略掉，就是非對(duì)稱加密算法選擇使用dh_anon，當(dāng)然這是特殊的情況，并且也不安全，所以這里就不展開討論。

server->client: 這是我的證書（身份證），請(qǐng)過目

ServerKeyExchange（可選）

在前面的ServerHello中，雙方已經(jīng)協(xié)商好了密碼套件，對(duì)于套件里面的非對(duì)稱加密算法，有些需要更多的信息才能生成一個(gè)可靠的密碼，而有些不需要，比如RSA，就不需要發(fā)送這個(gè)消息，客戶端自己生成一個(gè)準(zhǔn)密碼（premaster）就可以了，而有些算法，比如DHE_RSA，就需要發(fā)送一點(diǎn)特殊的信息給客戶端，便于它生成premaster。

premaster可以理解為最終密碼的初級(jí)版本，有了這個(gè)密碼之后，稍微再做一下計(jì)算就可以得到最終要使用的對(duì)稱加密的密碼

server->client: 這是生成premaster所需要的一些信息，請(qǐng)查收

CertificateRequest（可選）

只有在需要驗(yàn)證客戶端的身份的時(shí)候才用得著，在大部分情況下，尤其是HTTPS，這一步不需要。比如我們?cè)L問銀行的網(wǎng)站，我們只要保證那確實(shí)是銀行的網(wǎng)站就可以了，銀行驗(yàn)證我們是通過賬號(hào)密碼，而不是我們的證書。而U盾就是一個(gè)驗(yàn)證客戶端的例子，銀行給你的U盾里面有你的證書，你通過U盾訪問銀行的時(shí)候，銀行會(huì)驗(yàn)證U盾里面證書是不是你的，這種情況下，你和銀行之間進(jìn)行TLS握手的時(shí)候，銀行會(huì)給你發(fā)這個(gè)CertificateRequest請(qǐng)求。

server->client: 把你的證書（身份證）也給我看看，我要確認(rèn)一下你是不是XXX。

ServerHelloDone

server->client: 我要告訴你的就是這么多了，處理完了給我個(gè)回話吧。

Certificate（可選）

如果客戶端在前面收到了服務(wù)器的CertificateRequest請(qǐng)求，那么將會(huì)在這里給服務(wù)器發(fā)送自己的證書，就算自己沒有證書，也要發(fā)送這個(gè)消息告訴服務(wù)器端自己沒有證書，然后由服務(wù)器端來決定是否繼續(xù)。

client->server: 這是我的證書（身份證），請(qǐng)過目

ClientKeyExchange

客戶端驗(yàn)證完服務(wù)器端的證書后（怎么驗(yàn)證證書將在后面介紹），就會(huì)生成一個(gè)premaster，生成的方式跟采用的密碼交換算法有關(guān)，以TLS_RSA_WITH_AES_128_CBC_SHA為例，其密碼交換算法是RSA，于是客戶端自己直接生成一個(gè)48字節(jié)長度的premaster即可，不需要服務(wù)器發(fā)過來的ServerKeyExchange。

client->server: 
這是計(jì)算真正密碼要用到的premaster，它是用你證書里的公鑰加密了的哦，
記得用你的私鑰解密后才能看到哦

CertificateVerify（可選）

如果客戶端給服務(wù)器發(fā)了證書，就需要發(fā)送該消息給服務(wù)器，主要用于驗(yàn)證證書對(duì)應(yīng)的私鑰確實(shí)是在客戶端手里。

client->server: 
這是一段用我私鑰加密的數(shù)據(jù)，你用我給你的證書里的公鑰解密看看，
如果能解開，說明我沒騙你，私鑰確實(shí)是在我手里，
并不是我隨便找了一個(gè)別人的證書忽悠你

發(fā)送的消息里面都帶有校驗(yàn)碼，所以解密后計(jì)算下校驗(yàn)碼，能對(duì)上說明解密成功

Finished

當(dāng)前面的過程都沒問題后，服務(wù)器和客戶端都根據(jù)得到的信息計(jì)算對(duì)稱加密用的密碼，這是RFC里面給出的計(jì)算方法：

master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)
                          [0..47];

雖然不太了解PRF的細(xì)節(jié)，但至少客戶端和服務(wù)器端用的算法和輸入都是一樣的，所以得到的master密碼也是一樣的。這里pre_master_secret就是ClientKeyExchange里面客戶端發(fā)給服務(wù)器端的premaster，ClientHello.random和ServerHello.random分別是握手開始時(shí)雙方發(fā)送的hello請(qǐng)求中的隨機(jī)字符串。

這里加入隨機(jī)數(shù)的原因主要是為了防止重放攻擊，保證每次握手后得到的密碼都是不一樣的

然后雙方將自己緩存的握手過程中的數(shù)據(jù)計(jì)算一個(gè)校驗(yàn)碼，并用對(duì)稱加密算法和剛算出來的master密碼加密，發(fā)給對(duì)方，這一步有兩目的，一個(gè)是保證雙方算出來的master密碼都是一樣的，即我這邊加密的數(shù)據(jù)你那邊能解開；另一個(gè)目的是確保我們兩個(gè)人的通信過程中的每一步都沒有被其他人篡改，因?yàn)槲帐值那鞍氩糠侄际敲魑?，所以有可能被篡改，只要雙方根據(jù)各自緩存的握手過程的數(shù)據(jù)算出來的校驗(yàn)碼是一樣的，說明中間沒人篡改過。

client->server: 這是用我們協(xié)商的對(duì)稱加密算法和密碼加密過的握手?jǐn)?shù)據(jù)的指紋，看能不能解開，并且和你那邊算出來的指紋是一樣的
server->client: 這是用我們協(xié)商的對(duì)稱加密算法和密碼加密過的握手?jǐn)?shù)據(jù)的指紋，你也看看能不能解開，并且和你那邊算出來的指紋是一樣的

如果雙方發(fā)送完Finished而對(duì)方?jīng)]有報(bào)錯(cuò)，握手就完成了，雙發(fā)都得到了密碼，并且這個(gè)密碼別人不知道，后續(xù)的所有數(shù)據(jù)傳輸過程都會(huì)用這個(gè)密碼進(jìn)行加密，加密算法就是ServerHello里面協(xié)商好的對(duì)稱加密算法。

在上面握手的過程中，一旦有任何一方覺得有問題，都可能隨時(shí)終止握手過程

配置好了之后還是連不上，一般會(huì)是下面幾種問題：

版本不一致，有一方的版本太低，另一方為了安全不同意跟它通信

無法就cipher suite達(dá)成一致，有一方支持的加密算法太弱，安全程度不夠

證書有問題，沒法通過驗(yàn)證

服務(wù)器端需要驗(yàn)證客戶端的證書，而客戶端沒有配置

開始之前，看看我們常說的那些跟證書相關(guān)的概念

私鑰

私鑰就是一個(gè)算法名稱加上密碼串，自己保存，從不給任何人看

公鑰

公鑰也是一個(gè)算法名稱加上密碼串，一般不會(huì)多帶帶給別人，而是嵌在證書里面一起給別人

CA

專門用自己的私鑰給別人進(jìn)行簽名的單位或者機(jī)構(gòu)

申請(qǐng)（簽名）文件

在公鑰的基礎(chǔ)上加上一些申請(qǐng)人的屬性信息，比如我是誰，來自哪里，名字叫什么，證書適用于什么場景等的信息，然后帶上進(jìn)行的簽名，發(fā)給CA（私下安全的方式發(fā)送），帶上自己簽名的目的是為了防止別人篡改文件。

證書文件

證書由公鑰加上描述信息，然后經(jīng)過私鑰簽名之后得到，一般都是一個(gè)人的私鑰給另一個(gè)人的公鑰簽名，如果是自己的私鑰給自己的公鑰簽名，就叫自簽名。

簽名過程

CA收到申請(qǐng)文件后，會(huì)走核實(shí)流程，確保申請(qǐng)人確實(shí)是證書中描述的申請(qǐng)人，防止別人冒充申請(qǐng)者申請(qǐng)證書，核實(shí)通過后，會(huì)用CA的私鑰對(duì)申請(qǐng)文件進(jìn)行簽名，簽名后的證書包含申請(qǐng)者的基本信息，CA的基本信息，證書的使用年限，申請(qǐng)人的公鑰，簽名用到的摘要算法，CA的簽名。

簽完名之后，證書就可以用了。

別人認(rèn)不認(rèn)你的證書要看上面簽的是誰的名，所以簽名一定要找權(quán)威的人來簽，否則別人不認(rèn)，哪誰是權(quán)威的人呢？那就是CA，哪些CA是受人相信的呢？那就要看軟件的配置，配置相信誰就相信誰，比如瀏覽器里面默認(rèn)配置的那些，只要是那些CA簽名的證書，瀏覽器都會(huì)相信，而你自己寫的程序，可以由你自己指定信任的CA。

信任一個(gè)CA就是說你相信你手上拿到的CA的證書是正確的，這是安全的前提，CA的證書是怎么到你手里的，這個(gè)不屬于規(guī)范的范疇，不管你是U盤拷貝的，還是怎么弄來得，反正你得確保拿到的CA證書沒問題，比如瀏覽器、操作系統(tǒng)等，安裝好了之后里面就內(nèi)置了很多信任的CA的證書。

那么CA的證書又是誰簽的名呢？一般CA都是分級(jí)的，CA的證書都是由上一級(jí)的CA來簽名，而最上一級(jí)CA的證書是自簽名證書。

下面以瀏覽器為例，說明證書的驗(yàn)證過程：

在TLS握手的過程中，瀏覽器得到了網(wǎng)站的證書

打開證書，查看是哪個(gè)CA簽名的這個(gè)證書

在自己信任的CA庫中，找相應(yīng)CA的證書，

用CA證書里面的公鑰解密網(wǎng)站證書上的簽名，取出網(wǎng)站證書的校驗(yàn)碼（指紋），然后用同樣的算法（比如sha256）算出出網(wǎng)站證書的校驗(yàn)碼，如果校驗(yàn)碼和簽名中的校驗(yàn)碼對(duì)的上，說明這個(gè)證書是合法的，且沒被人篡改過

讀出里面的CN，對(duì)于網(wǎng)站的證書，里面一般包含的是域名

檢查里面的域名和自己訪問網(wǎng)站的域名對(duì)不對(duì)的上，對(duì)的上的話，就說明這個(gè)證書確實(shí)是頒發(fā)給這個(gè)網(wǎng)站的

到此為止檢查通過

如果瀏覽器發(fā)現(xiàn)證書有問題，一般是證書里面的簽名者不是瀏覽器認(rèn)為值得信任的CA，瀏覽器就會(huì)給出警告頁面，這時(shí)候需要謹(jǐn)慎，有可能證書被掉包了。如訪問12306網(wǎng)站，由于12306的證書是自己簽的名，并且瀏覽器不認(rèn)為12306是受信的CA，所以就會(huì)給警告，但是一旦你把12306的根證書安裝到了你的瀏覽器中，那么下次就不會(huì)警告了，因?yàn)槟闩渲昧藶g覽器讓它相信12306是一個(gè)受信的CA。

下面以實(shí)際的例子來看看怎么生成證書。

生成CA的私鑰和證書

#創(chuàng)建一個(gè)cert目錄，后續(xù)操作都在該目錄下進(jìn)行
dev@dev:~$ mkdir cert && cd cert

dev@dev:~/cert$ openssl req -newkey rsa:2048 -nodes -sha256 -keyout ca.key -x509 -days 365 -out ca.crt
......
Common Name (e.g. server FQDN or YOUR name) []:ca.com
......

-newkey rsa:2048：生成一個(gè)長度為2048的采用RSA算法的私鑰

-nodes：這個(gè)私鑰在本地存儲(chǔ)的時(shí)候不加密（可以通過其它參數(shù)來加密私鑰，這樣存儲(chǔ)比較安全）

-sha256：生成的證書里面使用sha256作為摘要算法

-keyout ca.key： 輸出私鑰到key.pem

-x509：證書文件格式為x509，目前TLS默認(rèn)只支持這種格式的證書

-days 365：證書有效期1年

-out ca.crt：生成的證書文件保存到ca.crt

生成的過程中會(huì)要求填一些信息，除了Common Name要取一個(gè)容易區(qū)分的名字之外，其它都可以隨便填寫，我們?cè)谶@里將它填為ca.com.

生成私鑰和證書簽名申請(qǐng)文件

dev@dev:~/cert$ openssl req -newkey rsa:2048 -nodes -sha256 -keyout domain.key -new -out domain.csr
......
Common Name (e.g. server FQDN or YOUR name) []:domain.com
......

#這里將CN設(shè)置成domain.com

這里和上面的區(qū)別就是這里是-new生成一個(gè)證書簽名申請(qǐng)文件，而上面用-x509生成一個(gè)自簽名文件，其它的參數(shù)意義都一樣。

從這里可以看出，CA的私鑰和普通人的私鑰沒什么區(qū)別，唯一的區(qū)別就是CA用私鑰自簽名的證書受別人相信，而普通人的自簽名證書別人不信，所以需要CA來給證書簽名。

使用CA的私鑰對(duì)申請(qǐng)文件進(jìn)行簽名

dev@dev:~/cert$ openssl x509 -CA ca.crt -CAkey ca.key -in domain.csr -req -days 365 -out domain.crt -CAcreateserial -sha256

由于需要往生成的證書里寫入簽名者的信息，所以這里需要ca.crt，因?yàn)橹挥羞@里有CA的描述信息，ca.key里面只有私鑰的信息。

查看證書內(nèi)容

上面生成的證書文件格式都是pem格式。通過下面這個(gè)命令可以看到證書的內(nèi)容：

dev@dev:~/cert$ openssl x509 -text -noout -in ca.crt
dev@dev:~/cert$ openssl x509 -text -noout -in domain.crt

回到最開始的問題，cacert，cert，key對(duì)應(yīng)于上面的哪些東西呢？ cacert就是CA的證書，cert就是程序自己的證書，key就是程序自己的私鑰。對(duì)于服務(wù)器來說，至少需要有自己的私鑰和證書，而對(duì)于客戶端來說，至少需要一個(gè)cacert，不然沒法驗(yàn)證服務(wù)器的證書是否正確。

服務(wù)器采用python開發(fā)，只需要指定server的私鑰和證書就可以了，代碼如下：

import BaseHTTPServer, SimpleHTTPServer
import ssl

httpd = BaseHTTPServer.HTTPServer(("localhost", 443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, keyfile="./domain.key", certfile="./domain.crt", server_side=True)
httpd.serve_forever()

將上面的代碼保存為server.py，然后啟動(dòng)服務(wù)：

#監(jiān)聽443端口需要root權(quán)限
dev@dev:~/cert$ sudo python server.py

這里使用大家都熟悉的curl作為客戶端來測試：

#直接訪問報(bào)錯(cuò)，提示證書驗(yàn)證失敗，
#那是因?yàn)閐omain.crt是我們自己的CA簽名的，curl根本就不認(rèn)識(shí)，更談不上相信它了
dev@dev:~/cert$ curl https://127.0.0.1
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
......

#參數(shù)中顯式的指定我們CA的證書，讓它成為curl信任的CA，這樣curl就認(rèn)為我們的證書沒問題了
#但curl還是報(bào)錯(cuò)，說這個(gè)證書是發(fā)給domain.com的，而不是127.0.0.1
dev@dev:~/cert$ curl --cacert ./ca.crt https://127.0.0.1
curl: (51) SSL: certificate subject name (domain.com) does not match target host name "127.0.0.1"

#往/etc/hosts加上一條記錄，設(shè)置域名domain.com的ip地址為127.0.0.1
dev@dev:~/cert$ sudo sh -c "echo "127.0.0.1 domain.com" >> /etc/hosts"

#然后通過域名來訪問，得到了服務(wù)器的正確返回
dev@dev:~/cert$ curl --cacert ./ca.crt  https://domain.com



Directory listing for /


ca.crt
ca.key
ca.srl
domain.crt
domain.csr
domain.key
server.py





#測試完成之后記得手動(dòng)將domain.com從/etc/hosts里面刪掉

Transport Layer Security
OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs