握手中的身份驗證的流程：
由《HTTPS權威指南》-協議學習筆記知道了握手協議中身份驗證流程，這裡再摘出一遍：
1、Client向Server say hello
2、Server將明文資訊（包含publicKey_server）用協商的雜湊演算法雜湊、編碼然後用privateKey_server加密製作成了簽名。將簽名以及明文資訊傳送給Client。
3、Client用協商的雜湊演算法計算明文的雜湊，使用publicKey_server解密伺服器的簽名，對比自己計算出的雜湊是否和伺服器給的雜湊一致。從而實現伺服器的身份驗證。
這樣做的危險：
危險1：
1、如果Attacker截獲了Client的say hello，可以把publicKey_attacker返回給Client，取得Client的信任，至此Attacker與Client建立了安全連線。
2、Attacker冒充Client向Server傳送say hello，至此Attacker與Server建立了安全連線。
3、這樣，Client對Server傳送的資訊都被Attacker截獲並解密了。
危險2：
1、伺服器可以否認自己傳送過的訊息。
如何避免？
Client信任一些第三方權威機構（CA），然後由這些CA對Server的證書（包含了publicKey_Server）進行簽名，Server提供這個被CA簽名的證書給Client驗證。
這樣就形成了信任流：Client 信任 CA， CA信任Server，So Client信任Server。從而達到Server的身份驗證。
PKI（public key infrastructure公鑰基礎設施）就是用來解決如何使用和驗證證書的。當前使用的是基於可信的第三方機構，也就是證書頒發機構CA簽發證書。
實現流程圖：
所涉及到的新名詞：
- 訂閱人：需要證書來提供安全服務的團體（例如伺服器）
- 登記機構（RA）：完成證書籤發的相關管理工作，例如對訂閱人身份驗證，然後才會去找CA簽發證書。
- CSR檔案：訂閱者的證書籤名申請，主要目的是攜帶公鑰資訊，並且證明訂閱人擁有對應的私鑰（通過簽名證明），CSR還設計攜帶額外的後設資料，但實際中並非所有的都用到了，CA一般都會覆蓋CRS檔案中的一些內容並且將其他資訊內建到證書裡面。
- CA：我們都信任的證書頒發機構，它會在確定申請使用者的身份之後簽發證書
- 信賴方：執行證書驗證的網頁瀏覽器，其他程式及作業系統（例如iOS）
- CRL,OCSP：當出現私鑰洩密或者不再需要使用時，就需要吊銷證書，CRL和OCSP是兩種吊銷標準。
- CRL（certificate revocation list,證書吊銷列表）：是一組為過期但是卻已經被吊銷的列表，CA維護了一個或多個這樣的列表，每一張證書需要在CRL分發點擴充套件中包含對應的CRL地址。CRL的最大問題在於它越來越大，實時查詢起來會很慢
- OCSP（online certificate status protocol，線上證書狀態協議），支援實時查詢
證書，中間CA證書，證書鏈，根證書
證書：包含公鑰，訂閱人相關資訊，以及證書頒發者數字簽名的數字檔案。證書讓我們可以交換，儲存和使用公鑰，是整個PKI體系的基礎組成元素。
中間CA證書：根CA是非常重要的，如果根CA的金鑰被洩漏了，那麼就可以簽發任意虛假證書，這時如果把根CA吊銷掉，所有使用過這個CA簽發的證書的網站都將無法訪問。所以直接由根證書籤發最終實體證書是不允許的。證書發行商們為了安全，通常會將這些根證書對應的私鑰儲存在絕對斷網的金庫裡。在金庫裡用這些根私鑰，簽發一些“中級”證書，這些中級證書的私鑰擁有簽發再下一級證書的許可權。這些中級私鑰被安裝到線上伺服器上，通過簽發網站證書來賺錢。一旦這些伺服器被黑，發行商就可以利用金庫裡物理隔離的根證書私鑰，可以簽發吊銷令，消滅這些中級證書的信任，而不必讓各家瀏覽器徹底不信任這家發行商的根證書。再籤一條新的中級發行證書，又是一條能賺錢的好漢。引自：SSL證書鏈不完整問題：中間證書果然是個坑。
根證書：根證書是CA給自己頒發的證書,是信任鏈的起始點。安裝根證書意味著對這個CA認證中心的信任。
證書鏈：CA在驗證成功之後就會簽發證書。除了證書本身，CA還會提供所有的中間證書，從而構成了證書鏈到對應的根證書上。因為信賴方只儲存著根證書，所以要通過證書鏈找到根證書來驗證。
使用證書進行身份驗證的流程
身份驗證流程：
1、信賴方新增可信任根證書庫，根證書庫中儲存著可信任的CA的根證書
例如Apple：
Apple維護的根證書庫主要是給iOS和OSX平臺使用，如果某個CA希望加入到Apple的根證書庫裡面的話，就需要通過權威機構審計並且對Apple的客戶有商業價值。
2、證書訂閱人找到信賴方所信賴的CA的登記機構，傳送CSR，申請簽名。
3、登記機構通過CA頒發給證書訂閱人證書。
4、信賴方要求伺服器進行身份驗證。
5、伺服器傳送證書鏈給信賴方。
6、信賴方通過自己的根證書庫對證書鏈進行驗證（驗證簽名是否正確，檢查證書是否已經吊銷）。
7、握手流程中的身份驗證結束，開始使用證書中的公鑰進行金鑰交換流程。
示例場景：
對於Client：
1、根CA有一個金庫，儲存著自己的私鑰：privateKey_CA
2、根CA把自己的根證書（使用自己的私鑰自簽名證書）植入到Client中，根證書包含著：publicKey_CA
3、基於上面兩個步驟，Client就可以驗證根CA的簽名了。
對於中間CA：
1、中間CA擁有根CA中的金庫的私鑰的簽名（獲取了根CA的信任），有派發子證書的權利。
對於Server：
1、Server將自己的CSR（包含publicKey_Server，但不包含privateKey_Server）給RA，RA稽核後給中間CA，請求中間CA簽名（相當於獲取中間CA的信任）。
2、中間CA使用自己的私鑰給Server的證書籤名。
對於Client驗證Server：
1、在Client要求驗證Server身份時，Server將由中間CA簽名的證書鏈發給Client。
2、Client可以從證書鏈尋找到根證書
3、Client從自己信任的根證書庫中尋找對應的根證書來驗證。
4、驗證通過後，使用publicKey_Server來開始握手流程中的金鑰交換。
參考文章：
ATS配置官方說明
蘋果強制使用HTTPS傳輸後APP開發者必須知道的事
SSL證書鏈不完整問題：中間證書果然是個坑。
關於iOS9中的App Transport Security相關說明及適配(更新於2016.7.1)
騰訊雲申請SSL證書
iOS使用自簽名證書實現HTTPS請求
iOS 升級HTTPS通過ATS你所要知道的
AFNetworking之於https認證
我的簡書主頁：www.jianshu.com/users/b92ab…