iOS 中对 HTTPS 证书链的验证
iOS 中对 HTTPS 证书链的验证 这篇文章是我一边学习证书验证一边记录的内容， 稍微整理了下，共扯了三部分内容：1.2. 3. HTTPS 简要原理； 数字证书的内容、生成及验证； iOS
iOS 中对 HTTPS 证书链的验证 这篇文章是我一边学习证书验证一边记录的内容， 稍微整理了下，共扯了三部分内容：
1.
2. 3. HTTPS 简要原理； 数字证书的内容、生成及验证； iOS 上对证书链的验证。 HTTPS 概要
HTTPS 是运行在 TLS/SSL 之上的 HTTP，与普通的 HTTP 相比，在数据传输的安全性上有很大的提升。 要了解它安全性的巧妙之处，需要先简单地了解对称加密和非对称加密的区别： 对称加密只有一个密钥，加密和解密都用这个密钥；
非对称加密有公钥和私钥，私钥加密后的内容只有公钥才能解密，公钥加密的内容只有私钥才能解密。
为了提高安全性，我们常用的做法是使用对称加密的手段加密数据。可是只使用对称加密的话，双方通信的开始总会以明文的方式传输密钥。那么从一开始这个密钥就泄露了，谈不上什么安全。所以 TLS/SSL 在握手的阶段，结合非对称加密的手段，保证只有通信双方才知道对称加密的密钥。大概的流程如下： ∙ ∙
,
TSL:SSL_handshake.png
所以，HTTPS 实现传输安全的关键是：在 TLS/SSL 握手阶段保证仅有通信双方得到 Session Key！
数字证书的内容
X.509 应该是比较流行的 SSL 数字证书标准，包含（但不限于）以下的字段：
,
下图为 Wikipedia 的公钥证书：
,
wikipedia_cer.png
数字证书的生成及验证
数字证书的生成是分层级的，下一级的证书需要其上一级证书的私钥签名。 所以后者是前者的证书颁发者，也就是说上一级证书的 Subject Name 是其下一级证书的 Issuer Name。
,在得到证书申请者的一些必要信息（对象名称，公钥私钥）之后，证书颁发者通过 SHA-256 哈希得到证书内容的摘要，再用自己的私钥给这份摘要加密，得到数字签名。综合已有的信息，生成分别包含公钥和私钥的两个证书。 扯到这里，就有几个问题：
问：如果说发布一个数字证书必须要有上一级证书的私钥加密，那么最顶端的证书——根证书怎么来的？ 根证书是自签名的，即用自己的私钥签名，不需要其他证书的私钥
来生成签名。
问：怎么验证证书是有没被篡改？ 当客户端走 HTTPS 访问站点时，服务器会返回整个证书链。以下图的证书链为例：
chain_hierarchy.png
要验证 *.wikipedia.org 这个证书有没被篡改，就要用
到 GlobalSign Organization Validation CA - SHA256 - G2 提
供的公钥解密前者的签名得到摘要 Digest1，我们的客户端也计算
前者证书的内容得到摘要 Digest2。对比这两个摘要就能知道前者
是否被篡改。后者同理，使用 GlobalSign Root CA 提供的公钥
验证。当验证到到受信任的根证书时，就能确
定 *.wikipedia.org 这个证书是可信的。
问：为什么上面那个根证书 GlobalSign Root CA 是受信任的？
数字证书认证机构（Certificate Authority, CA）签署和管理
的 CA 根证书，会被纳入到你的浏览器和操作系统的可信证书列
表中，并由这个列表判断根证书是否可信。所以不要随便导入奇奇
怪怪的根证书到你的操作系统中。
问：生成的数字证书（如 *.wikipedia.org）都可用来签署新的证书吗？
不一定。如下图，拓展字段里面有个叫 Basic Constraints 的数
据结构，里面有个字段叫路径长度约束（Path Length Constraint ），
表明了该证书能继续签署 CA 子证书的深度，这里为0，说明这
个 GlobalSign Organization Validation CA - SHA256 - G2 只
能签署客户端证书，而客户端证书不能用于签署新的证书，CA 子
证书才能这么做。
,
path_length_constraint.png
iOS 上对证书链的验证
在 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 中，证书是否有效的标准是：
信任链中如果只含有有效证书并且以可信锚点（trusted anchor）结尾，那么这个证书就被认为是有效的。
其中可信锚点指的是系统隐式信任的证书，通常是包括在系统中的 CA 根证书。不过你也可以在验证证书链时，设置自定义的证书作为可信的锚点。
,NSURLSession 实现 HTTPS
具体到使用 NSURLSession 走 HTTPS 访问网站，-URLSession:didReceiveChallenge:completionHandler: 回调中会收到一个 challenge ，也就是质询，需要你提供认证信息才能完成连接。这时候可以通过 challenge.protectionSpace.authenticationMethod 取得保护空间要求我们认证的方式，如果这个值是 NSURLAuthenticationMethodServerTrust 的话，我们就可以插手 TLS 握手中“验证数字证书有效性”这一步。
默认的实现
系统的默认实现（也即代理不实现这个方法）是验证这个信任链，结果是有效的话则根据 serverTrust 创建 credential 用于同服务端确立 SSL 连接。否则会得到 “The certificate for this server is invalid...”
这样的错误而无法访问。
比如在访问 https://www-google-com 的时候咧，我们不实现这个方法也能访问成功的。系统对 Google 服务器返回来的证书链，从叶节点证书往根证书层层验证（有效期、签名等等），遇到根证书时，发现作为可信锚点的它存在与可信证书列表中，那么验证就通过，允许与服务端建立连接。
google.png
而当我们访问 https://www-12306-cn 时，就会出现 "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." 的错误。原因就是系统在验证到根证书时，发现它是自签名、不可信的。
12306.png
自定义实现
如果我们要实现这个代理方法的话，需要提供 NSURLSessionAuthChallengeDisposition （处置方式）和 NSURLCredential（资格认证）这两个参数给 completionHandler 这个 block：
-(void )URLSession:(NSURLSession *)session
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposit ion ,
NSURLCredential * _Nullable))completionHandler {
// 如果使用默认的处置方式，那么 credential 就会被忽略
NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthCh allengePerformDefaultHandling ;
,NSURLCredential *credential = nil;
if ([challenge.protectionSpace.authenticationMethod
isEqualToString:
NSURLAuthenticationMethodServerTrust ]) {
/* 调用自定义的验证过程 */
if ([self myCustomValidation:challenge]) {
credential = [NSURLCredential credentialForTrust:challenge .protectionSpace.serverTrust ];
if (credential) {
disposition = NSURLSessionAuthChallengeUseCredential ; }
} else {
/* 无效的话，取消 */
disposition = NSURLSessionAuthChallengeCancelAuthenticati onChallenge
}
}
if (completionHandler) {
completionHandler(disposition, credential);
}
}
在 [self myCustomValidation:challenge] 调用自定义验证过程，结果是有效的话才创建 credential 确立连接。
自定义的验证过程，需要先拿出一个 SecTrustRef 对象，它是一种执行信任链验证的抽象实体，包含着验证策略（SecPolicyRef ）以及一系列受信任的锚点证书，而我们能做的也是修改这两样东西而已。
,SecTrustRef trust = challenge.protectionSpace.serverTrust;
拿到 trust 对象之后，可以用下面这个函数对它进行验证。 static BOOL serverTrustIsVaild(SecTrustRef trust) { BOOL allowConnection = NO;
// 假设验证结果是无效的 SecTrustResultType trustResult = kSecTrustResultInvalid;
// 函数的内部递归地从叶节点证书到根证书的验证 OSStatus statue = SecTrustEvaluate(trust, &trustResult);
if (statue == noErr) {
// kSecTrustResultUnspecified: 系统隐式地信任这个证书
// kSecTrustResultProceed: 用户加入自己的信任锚点，显式地告诉系统这个证书是值得信任的
allowConnection = (trustResult == kSecTrustResultProceed
|| trustResult == kSecTrustResultUnspecified);
}
return allowConnection;
}
这个函数什么时候调用完全取决于你的需求，如果你不想对验证策略做修改而直接调用的话，那你居然还看到这里！？(╯‵□′) ╯︵┻━┻
域名验证
可以通过以下的代码获得当前的验证策略：
CFArrayRef policiesRef;
SecTrustCopyPolicies(trust , &policiesRef) ;