iOS 中对 HTTPS 证书链验证.docxVIP

iOS 中对 HTTPS 证书链的验证这篇文章是我一边学习证书验证一边记录的内容，稍微整理了下，共扯了三部分内容：HTTPS 简要原理；数字证书的内容、生成及验证；iOS 上对证书链的验证。HTTPS 概要HTTPS 是运行在 TLS/SSL 之上的 HTTP，与普通的 HTTP 相比，在数据传输的安全性上有很大的提升。要了解它安全性的巧妙之处，需要先简单地了解对称加密和非对称加密的区别：对称加密只有一个密钥，加密和解密都用这个密钥；非对称加密有公钥和私钥，私钥加密后的内容只有公钥才能解密，公钥加密的内容只有私钥才能解密。为了提高安全性，我们常用的做法是使用对称加密的手段加密数据。可是只使用对称加密的话，双方通信的开始总会以明文的方式传输密钥。那么从一开始这个密钥就泄露了，谈不上什么安全。所以 TLS/SSL 在握手的阶段，结合非对称加密的手段，保证只有通信双方才知道对称加密的密钥。大概的流程如下：TSL:SSL_handshake.png所以，HTTPS 实现传输安全的关键是：在 TLS/SSL 握手阶段保证仅有通信双方得到 Session Key！数字证书的内容X.509 应该是比较流行的 SSL 数字证书标准，包含（但不限于）以下的字段：字段值说明对象名称（Subject Name）用于识别该数字证书的信息共有名称（Common Name）对于客户证书，通常是相应的域名证书颁发者（Issuer Name）发布并签署该证书的实体的信息签名算法（Signature Algorithm）签名所使用的算法序列号（Serial Number）数字证书机构（Certificate Authority， CA）给证书的唯一整数，一个数字证书一个序列号生效期（Not Valid Before）(｀?ω?′)失效期（Not Valid After）(╯°口°)╯(┴—┴公钥（Public Key）可公开的密钥签名（Signature）通过签名算法计算证书内容后得到的数据，用于验证证书是否被篡改除了上述所列的字段，还有很多拓展字段，在此不一一详述。下图为 Wikipedia 的公钥证书：wikipedia_cer.png数字证书的生成及验证数字证书的生成是分层级的，下一级的证书需要其上一级证书的私钥签名。所以后者是前者的证书颁发者，也就是说上一级证书的 Subject Name 是其下一级证书的 Issuer Name。在得到证书申请者的一些必要信息（对象名称，公钥私钥）之后，证书颁发者通过 SHA-256 哈希得到证书内容的摘要，再用自己的私钥给这份摘要加密，得到数字签名。综合已有的信息，生成分别包含公钥和私钥的两个证书。扯到这里，就有几个问题：问：如果说发布一个数字证书必须要有上一级证书的私钥加密，那么最顶端的证书——根证书怎么来的？根证书是自签名的，即用自己的私钥签名，不需要其他证书的私钥来生成签名。问：怎么验证证书是有没被篡改？当客户端走 HTTPS 访问站点时，服务器会返回整个证书链。以下图的证书链为例：chain_hierarchy.png要验证?*.?这个证书有没被篡改，就要用到?GlobalSign Organization Validation CA - SHA256 - G2?提供的公钥解密前者的签名得到摘要 Digest1，我们的客户端也计算前者证书的内容得到摘要 Digest2。对比这两个摘要就能知道前者是否被篡改。后者同理，使用?GlobalSign Root CA?提供的公钥验证。当验证到到受信任的根证书时，就能确定?*.?这个证书是可信的。问：为什么上面那个根证书?GlobalSign Root CA?是受信任的？数字证书认证机构（Certificate Authority, CA）签署和管理的?CA 根证书，会被纳入到你的浏览器和操作系统的可信证书列表中，并由这个列表判断根证书是否可信。所以不要随便导入奇奇怪怪的根证书到你的操作系统中。问：生成的数字证书（如?*.）都可用来签署新的证书吗？不一定。如下图，拓展字段里面有个叫 Basic Constraints 的数据结构，里面有个字段叫路径长度约束（Path Length Constraint），表明了该证书能继续签署 CA 子证书的深度，这里为0，说明这个?GlobalSign Organization Validation CA - SHA256 - G2?只能签署客户端证书，而客户端证书不能用于签署新的证书，CA 子证书才能这么做。path_length_constraint.pngiOS 上对证书链的验证在?Overriding TLS Chain Validation Correctly?中提到：When a TLS certificate is v