内容发布更新时间 : 2024/12/31 3:56:17星期一 下面是文章的全部内容请认真阅读。

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 时，就会出现 \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 (^)(NSURLSessionAuthChallengeDisposition,

NSURLCredential * _Nullable))completionHandler {

// 如果使用默认的处置方式，那么 credential 就会被忽略

NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;

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 = NSURLSessionAuthChallengeCancelAuthenticationChallenge } }

if (completionHandler) {

completionHandler(disposition, credential); } }

在 [self myCustomValidation:challenge] 调用自定义验证过程，结果是有效的话才创建 credential 确立连接。

自定义的验证过程，需要先拿出一个 SecTrustRef 对象，它是一种执行信任链验证的抽象实体，包含着验证策略（SecPolicyRef）以及一系列受信任的锚点证书，而我们能做的也是修改这两样东西而已。

SecTrustRef trust = challenge.protectionSpace.serverTrust; 拿到 trust 对象之后，可以用下面这个函数对它进行验证。 staticBOOL 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);