iOS 中對(duì) HTTPS 證書鏈的驗(yàn)證 這篇文章是我一邊學(xué)習(xí)證書驗(yàn)證一邊記錄的內(nèi)容， 稍微整理了下，共扯了三部分內(nèi)容：1.2. 3. HTTPS 簡(jiǎn)要原理； 數(shù)字證書的內(nèi)容、生成及驗(yàn)證； iOS

iOS 中對(duì) HTTPS 證書鏈的驗(yàn)證 這篇文章是我一邊學(xué)習(xí)證書驗(yàn)證一邊記錄的內(nèi)容， 稍微整理了下，共扯了三部分內(nèi)容：

1.

2. 3. HTTPS 簡(jiǎn)要原理； 數(shù)字證書的內(nèi)容、生成及驗(yàn)證； iOS 上對(duì)證書鏈的驗(yàn)證。 HTTPS 概要

HTTPS 是運(yùn)行在 TLS/SSL 之上的 HTTP，與普通的 HTTP 相比，在數(shù)據(jù)傳輸?shù)陌踩陨嫌泻艽蟮奶嵘?要了解它安全性的巧妙之處，需要先簡(jiǎn)單地了解對(duì)稱加密和非對(duì)稱加密的區(qū)別： 對(duì)稱加密只有一個(gè)密鑰，加密和解密都用這個(gè)密鑰；

非對(duì)稱加密有公鑰和私鑰，私鑰加密后的內(nèi)容只有公鑰才能解密，公鑰加密的內(nèi)容只有私鑰才能解密。

為了提高安全性，我們常用的做法是使用對(duì)稱加密的手段加密數(shù)據(jù)。可是只使用對(duì)稱加密的話，雙方通信的開始總會(huì)以明文的方式傳輸密鑰。那么從一開始這個(gè)密鑰就泄露了，談不上什么安全。所以 TLS/SSL 在握手的階段，結(jié)合非對(duì)稱加密的手段，保證只有通信雙方才知道對(duì)稱加密的密鑰。大概的流程如下： ? ?

TSL:SSL_handshake.png

所以，HTTPS 實(shí)現(xiàn)傳輸安全的關(guān)鍵是：在 TLS/SSL 握手階段保證僅有通信雙方得到 Session Key！

數(shù)字證書的內(nèi)容

X.509 應(yīng)該是比較流行的 SSL 數(shù)字證書標(biāo)準(zhǔn)，包含（但不限于）以下的字段：

下圖為 Wikipedia 的公鑰證書：

wikipedia_cer.png

數(shù)字證書的生成及驗(yàn)證

數(shù)字證書的生成是分層級(jí)的，下一級(jí)的證書需要其上一級(jí)證書的私鑰簽名。 所以后者是前者的證書頒發(fā)者，也就是說(shuō)上一級(jí)證書的 Subject Name 是其下一級(jí)證書的 Issuer Name。

在得到證書申請(qǐng)者的一些必要信息（對(duì)象名稱，公鑰私鑰）之后，證書頒發(fā)者通過(guò) SHA-256 哈希得到證書內(nèi)容的摘要，再用自己的私鑰給這份摘要加密，得到數(shù)字簽名。綜合已有的信息，生成分別包含公鑰和私鑰的兩個(gè)證書。 扯到這里，就有幾個(gè)問(wèn)題：

問(wèn)：如果說(shuō)發(fā)布一個(gè)數(shù)字證書必須要有上一級(jí)證書的私鑰加密，那么最頂端的證書——根證書怎么來(lái)的？ 根證書是自簽名的，即用自己的私鑰簽名，不需要其他證書的私鑰

來(lái)生成簽名。

問(wèn)：怎么驗(yàn)證證書是有沒(méi)被篡改？ 當(dāng)客戶端走 HTTPS 訪問(wèn)站點(diǎn)時(shí)，服務(wù)器會(huì)返回整個(gè)證書鏈。以下圖的證書鏈為例：

chain_hierarchy.png

要驗(yàn)證 *.wikipedia.org 這個(gè)證書有沒(méi)被篡改，就要用

到 GlobalSign Organization Validation CA - SHA256 - G2 提

供的公鑰解密前者的簽名得到摘要 Digest1，我們的客戶端也計(jì)算

前者證書的內(nèi)容得到摘要 Digest2。對(duì)比這兩個(gè)摘要就能知道前者

是否被篡改。后者同理，使用 GlobalSign Root CA 提供的公鑰

驗(yàn)證。當(dāng)驗(yàn)證到到受信任的根證書時(shí)，就能確

定 *.wikipedia.org 這個(gè)證書是可信的。

問(wèn)：為什么上面那個(gè)根證書 GlobalSign Root CA 是受信任的？

數(shù)字證書認(rèn)證機(jī)構(gòu)（Certificate Authority, CA）簽署和管理

的 CA 根證書，會(huì)被納入到你的瀏覽器和操作系統(tǒng)的可信證書列

表中，并由這個(gè)列表判斷根證書是否可信。所以不要隨便導(dǎo)入奇奇

怪怪的根證書到你的操作系統(tǒng)中。

問(wèn)：生成的數(shù)字證書（如 *.wikipedia.org）都可用來(lái)簽署新的證書嗎？

不一定。如下圖，拓展字段里面有個(gè)叫 Basic Constraints 的數(shù)

據(jù)結(jié)構(gòu)，里面有個(gè)字段叫路徑長(zhǎng)度約束（Path Length Constraint ），

表明了該證書能繼續(xù)簽署 CA 子證書的深度，這里為0，說(shuō)明這

個(gè) GlobalSign Organization Validation CA - SHA256 - G2 只

能簽署客戶端證書，而客戶端證書不能用于簽署新的證書，CA 子

證書才能這么做。

path_length_constraint.png

iOS 上對(duì)證書鏈的驗(yàn)證

在 Overriding TLS Chain Validation Correctly 中提到：

When a TLS certificate is verified, the operating system

verifies its chain of trust. If that chain of trust contains

only valid certificates and ends at a known (trusted) anchor

certificate, then the certificate is considered valid.

所以在 iOS 中，證書是否有效的標(biāo)準(zhǔn)是：

信任鏈中如果只含有有效證書并且以可信錨點(diǎn)（trusted anchor）結(jié)尾，那么這個(gè)證書就被認(rèn)為是有效的。

其中可信錨點(diǎn)指的是系統(tǒng)隱式信任的證書，通常是包括在系統(tǒng)中的 CA 根證書。不過(guò)你也可以在驗(yàn)證證書鏈時(shí)，設(shè)置自定義的證書作為可信的錨點(diǎn)。

NSURLSession 實(shí)現(xiàn) HTTPS

具體到使用 NSURLSession 走 HTTPS 訪問(wèn)網(wǎng)站，-URLSession:didReceiveChallenge:completionHandler: 回調(diào)中會(huì)收到一個(gè) challenge ，也就是質(zhì)詢，需要你提供認(rèn)證信息才能完成連接。這時(shí)候可以通過(guò) challenge.protectionSpace.authenticationMethod 取得保護(hù)空間要求我們認(rèn)證的方式，如果這個(gè)值是 NSURLAuthenticationMethodServerTrust 的話，我們就可以插手 TLS 握手中“驗(yàn)證數(shù)字證書有效性”這一步。

默認(rèn)的實(shí)現(xiàn)

系統(tǒng)的默認(rèn)實(shí)現(xiàn)（也即代理不實(shí)現(xiàn)這個(gè)方法）是驗(yàn)證這個(gè)信任鏈，結(jié)果是有效的話則根據(jù) serverTrust 創(chuàng)建 credential 用于同服務(wù)端確立 SSL 連接。否則會(huì)得到 “The certificate for this server is invalid...”

這樣的錯(cuò)誤而無(wú)法訪問(wèn)。

比如在訪問(wèn) https://www-google-com 的時(shí)候咧，我們不實(shí)現(xiàn)這個(gè)方法也能訪問(wèn)成功的。系統(tǒng)對(duì) Google 服務(wù)器返回來(lái)的證書鏈，從葉節(jié)點(diǎn)證書往根證書層層驗(yàn)證（有效期、簽名等等），遇到根證書時(shí)，發(fā)現(xiàn)作為可信錨點(diǎn)的它存在與可信證書列表中，那么驗(yàn)證就通過(guò)，允許與服務(wù)端建立連接。

google.png

而當(dāng)我們?cè)L問(wèn) https://www-12306-cn 時(shí)，就會(huì)出現(xiàn) "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “www-12306-cn ” which could put your confidential

information at risk." 的錯(cuò)誤。原因就是系統(tǒng)在驗(yàn)證到根證書時(shí)，發(fā)現(xiàn)它是自簽名、不可信的。

12306.png

自定義實(shí)現(xiàn)

如果我們要實(shí)現(xiàn)這個(gè)代理方法的話，需要提供 NSURLSessionAuthChallengeDisposition （處置方式）和 NSURLCredential（資格認(rèn)證）這兩個(gè)參數(shù)給 completionHandler 這個(gè) block：

-(void )URLSession:(NSURLSession *)session

didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposit ion ,

NSURLCredential * _Nullable))completionHandler {

// 如果使用默認(rèn)的處置方式，那么 credential 就會(huì)被忽略

NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthCh allengePerformDefaultHandling ;

NSURLCredential *credential = nil;

if ([challenge.protectionSpace.authenticationMethod

isEqualToString:

NSURLAuthenticationMethodServerTrust ]) {

/* 調(diào)用自定義的驗(yàn)證過(guò)程 */

if ([self myCustomValidation:challenge]) {

credential = [NSURLCredential credentialForTrust:challenge .protectionSpace.serverTrust ];

if (credential) {

disposition = NSURLSessionAuthChallengeUseCredential ; }

} else {

/* 無(wú)效的話，取消 */

disposition = NSURLSessionAuthChallengeCancelAuthenticati onChallenge

}

}

if (completionHandler) {

completionHandler(disposition, credential);

}

}

在 [self myCustomValidation:challenge] 調(diào)用自定義驗(yàn)證過(guò)程，結(jié)果是有效的話才創(chuàng)建 credential 確立連接。

自定義的驗(yàn)證過(guò)程，需要先拿出一個(gè) SecTrustRef 對(duì)象，它是一種執(zhí)行信任鏈驗(yàn)證的抽象實(shí)體，包含著驗(yàn)證策略（SecPolicyRef ）以及一系列受信任的錨點(diǎn)證書，而我們能做的也是修改這兩樣?xùn)|西而已。

SecTrustRef trust = challenge.protectionSpace.serverTrust;

拿到 trust 對(duì)象之后，可以用下面這個(gè)函數(shù)對(duì)它進(jìn)行驗(yàn)證。 static BOOL serverTrustIsVaild(SecTrustRef trust) { BOOL allowConnection = NO;

// 假設(shè)驗(yàn)證結(jié)果是無(wú)效的 SecTrustResultType trustResult = kSecTrustResultInvalid;

// 函數(shù)的內(nèi)部遞歸地從葉節(jié)點(diǎn)證書到根證書的驗(yàn)證 OSStatus statue = SecTrustEvaluate(trust, &trustResult);

if (statue == noErr) {

// kSecTrustResultUnspecified: 系統(tǒng)隱式地信任這個(gè)證書

// kSecTrustResultProceed: 用戶加入自己的信任錨點(diǎn)，顯式地告訴系統(tǒng)這個(gè)證書是值得信任的

allowConnection = (trustResult == kSecTrustResultProceed

|| trustResult == kSecTrustResultUnspecified);

}

return allowConnection;

}

這個(gè)函數(shù)什么時(shí)候調(diào)用完全取決于你的需求，如果你不想對(duì)驗(yàn)證策略做修改而直接調(diào)用的話，那你居然還看到這里??？(╯‵□′) ╯︵┻━┻

域名驗(yàn)證

可以通過(guò)以下的代碼獲得當(dāng)前的驗(yàn)證策略：

CFArrayRef policiesRef;

SecTrustCopyPolicies(trust , &policiesRef) ;