上一篇TLS簡介

本文中假定C需要驗(yàn)證S的身份台丛。

上一篇中提到了C和S如何互相證明我是我的問題善榛，并且提到了非對稱密鑰算法缚柏。我們提到苹熏，在S與C的發(fā)起通信時(shí)，S要向C證明自己是自己币喧，需要先給C一份公鑰轨域，并且C已經(jīng)相信這是S的公鑰。C發(fā)送給S的憑證稱為公鑰證書杀餐。

在內(nèi)部網(wǎng)絡(luò)中干发，C已經(jīng)相信這是S的公鑰可以通過網(wǎng)絡(luò)管理員預(yù)先將S的證書放置到C的基礎(chǔ)信任集合里來保證。但實(shí)際上互聯(lián)網(wǎng)公開網(wǎng)絡(luò)中史翘，比如普通用戶通過瀏覽器使用https訪問某家公司的網(wǎng)站時(shí)枉长，證書會在通信過程中由服務(wù)端發(fā)送給客戶端，此時(shí)客戶端C如何判斷這個(gè)證書是否可信呢琼讽？

如何信任一個(gè)未知的東西必峰？人不可能憑空去信任一個(gè)不認(rèn)識的人，通常需要有另一個(gè)已經(jīng)熟知的人做介紹跨琳。計(jì)算機(jī)領(lǐng)域也一樣自点。信任需要首先有一個(gè)基礎(chǔ)的信任集合，然后這個(gè)集合可以告訴客戶端哪些人可以信任脉让。這個(gè)集合被稱為信任根桂敛。比如在通過瀏覽器訪問https網(wǎng)站的過程中，系統(tǒng)中已經(jīng)內(nèi)置了包含了一些CA(Certificate authority)的證書溅潜，這些證書已經(jīng)被假定為可信术唬。CA是指頒發(fā)證書的機(jī)構(gòu)，在這里不做過多介紹滚澜。

有了信任根之后就可以建立信任鏈粗仓。其基礎(chǔ)想法是：如果客戶端已經(jīng)相信了A，A向客戶端承諾B可信，那么客戶端也就可以相信B借浊。通過這種鏈條機(jī)制塘淑，客戶端可以判斷一個(gè)新的陌生的通信方是否可信。

A如何承諾B可信蚂斤？A需要傳達(dá)出的信息A信任B存捺，且客戶端能驗(yàn)證這段信息確實(shí)由A傳達(dá)。密碼學(xué)通過簽名來實(shí)現(xiàn)這個(gè)目標(biāo)曙蒸。

通常意義上的簽名過程是人在一份文件上寫上自己的名字捌治，然后驗(yàn)證方看看簽名的筆跡是否是本人親筆書寫。在密碼學(xué)領(lǐng)域纽窟，簽名的概念與此類似肖油，它表示用自己的私鑰對一段內(nèi)容的哈希碼加密，用于承諾內(nèi)容經(jīng)過了自己的認(rèn)證臂港∩梗客戶端接受到內(nèi)容和簽名后，算出內(nèi)容的哈希碼审孽，用公鑰解密出簽名對應(yīng)的哈希碼疲恢，比對兩個(gè)哈希碼是否相同，從而判斷出簽名的內(nèi)容是否可信瓷胧。
內(nèi)容本身不需要加密。比如在上面的場景中棚愤，A信任B本身就是一個(gè)需要公開的內(nèi)容搓萧，需要驗(yàn)證的是A信任B這個(gè)內(nèi)容確實(shí)是A承諾的。因此宛畦，簽名算法只需要對內(nèi)容生成的哈希碼加密瘸洛。

上文講述了信任鏈的基礎(chǔ)思路，客戶端信任A次和， A信任B反肋，則客戶端可以信任B。
如果這個(gè)時(shí)候B承諾信任C踏施，客戶端A是否可以信任C?
在鏈條式信任下石蔗，回答是肯定的。但在實(shí)際使用場景中畅形，A承諾相信B既可能是A相信B和所有B相信的對象养距，或者A承諾相信B，但不一定相信其相信的對象日熬。因此棍厌，信任鏈上存在終端節(jié)點(diǎn)，終端節(jié)點(diǎn)不能再繼續(xù)延長信任鏈。

對應(yīng)到證書上耘纱，需要對證書進(jìn)行分類：根證書敬肚，中間證書，終端實(shí)體證書束析。 根證書和中間證書可以用來傳遞信任鏈艳馒，終端實(shí)體證書不能傳遞信任鏈。
根證書是內(nèi)置在客戶端的證書畸陡，是客戶端的基礎(chǔ)信任集合鹰溜，證書驗(yàn)證的過程中，最終都會對應(yīng)到對根證書的驗(yàn)證丁恭。
比如chrome瀏覽器有內(nèi)置的證書管理曹动，通過頁面chrome://settings/certificates可以查看和管理證書。

證書支持撤銷機(jī)制牲览，如果所有的終端實(shí)體證書都直接由根證書來直接認(rèn)證墓陈，那么任意一個(gè)實(shí)體變得不可信都需要直接更改根證書；因此第献，采用分而治之的策略：根證書簽名中間證書贡必，中間證書簽名中間證書（多級管理），最終簽名終端實(shí)體的方式來管理證書庸毫。

終端實(shí)體證書就是被證明可信任的實(shí)體仔拟，其中包含了實(shí)體的身份信息。終端實(shí)體證書不能用于簽名其他證書飒赃。

因此利花，對于上面的問題，回答是：只有當(dāng)B擁有的是中間證書的時(shí)候载佳，他才能使客戶端去信任其他實(shí)體炒事。

通過上面的描述，我們知道
公鑰證書中主要的信息是：

• 公鑰
• 公鑰持有人信息
• ( 信任鏈的上端)對證書內(nèi)容的簽名蔫慧。

TLS協(xié)議使用X509規(guī)范定義的公鑰證書的格式挠乳。
X509證書包含了以下內(nèi)容：
1、X.509版本號姑躲。
2睡扬、證書持有人的公鑰。
3肋联、證書的序列號：由CA給予每一個(gè)證書分配的唯一的數(shù)字型編號威蕉。
4、主題信息：證書持有人唯一的標(biāo)識符(或稱DN-distinguished name)這個(gè)名字在 Internet上應(yīng)該是唯一的橄仍。這個(gè)信息在申請證書時(shí)需要填寫
5韧涨、證書的有效期：證書起始日期和時(shí)間以及終止日期和時(shí)間牍戚；指明證書在這兩個(gè)時(shí)間內(nèi)有效。
6虑粥、認(rèn)證機(jī)構(gòu)：證書發(fā)布者如孝，是簽發(fā)該證書的實(shí)體唯一的CA的X.509名字。使用該證書意味著信任簽發(fā)證書的實(shí)體娩贷。(注意：在某些情況下第晰，比如根或頂級CA證書，發(fā)布者自己簽發(fā)證書)
7彬祖、發(fā)布者的數(shù)字簽名：這是使用發(fā)布者私鑰生成的簽名茁瘦，以確保這個(gè)證書在發(fā)放之后沒有被撰改過。
8储笑、簽名算法標(biāo)識符甜熔。

X509證書中使用擴(kuò)展字段‵CA:false‵來禁止信任鏈繼續(xù)傳遞。

X509v3 extensions:
     X509v3 Basic Constraints: 
                CA:FALSE

openssl 生成證書

上文中講述了證書的信任鏈機(jī)制和證書中應(yīng)當(dāng)包含的內(nèi)容突倍，本節(jié)中說明如何通過openssl來生成證書和查看證書腔稀。
所有的證書都起源是被預(yù)先置于客戶端的根證書，根證書中包含的公鑰可以直接驗(yàn)證其簽名羽历。我們通過openssl來生成一個(gè)根證書焊虏。
前文已經(jīng)提到證書基于非對稱密鑰機(jī)制，因此首先需要生成一對非對稱密鑰：

$ openssl genrsa -out rsa_private.key 2048

genrsa 指非對稱算法的類型秕磷，2048表示密鑰的長度诵闭。
盡管這里的名字是 rsa_private.key ，但實(shí)際上這個(gè)key里也包含可以推導(dǎo)出了公鑰和用于加密流程的私鑰信息澎嚣，算法涂圆，位數(shù)等基本信息。
可以通過以下信息查看生成的密鑰信息：

openssl rsa -in rsa_private.key -noout -text

從私鑰信息中提取出公鑰

$ openssl rsa -in rsa_private.key -pubout -out rsa_public.key

獲得了公鑰币叹。
前文中已經(jīng)提到，根證書是可以自驗(yàn)證的證書模狭，因此颈抚，生成證書只需要輸入所有者信息(在X509中用DN， Distinguished Name) 標(biāo)志嚼鹉，并用私鑰對其簽名

$ openssl req -new -x509 -days 365 -key rsa_private.key -out cert.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CH
State or Province Name (full name) [Some-State]:test
Locality Name (eg, city) []:test
Organization Name (eg, company) [Internet Widgits Pty Ltd]:test
Organizational Unit Name (eg, section) []:test
Common Name (e.g. server FQDN or YOUR name) []:test
Email Address []:test@test.com

-new 指生成證書請求贩汉，-x509 指定證書格式，-key 指定私鑰文件锚赤，-days365 為有效期
自此匹舞，我們已經(jīng)生成了私鑰，公鑰及根證書线脚。