本文借鉴于： http://www.cnblogs.com/oc-bowen/p/5896041.html
最近研究一些关于https的使用，看了下一些相关资料，主要分为三个部分
1. HTTPS 简要原理
2. 数学证书的内容，生产以及验证
3.iOS上对证书链的验证
HTTPS 概要
HTTPS 是运行在 TLS/SSL 之上的 HTTP，与普通的 HTTP 相比，在数据传输的安全性上有很大的提升。
要了解它安全性的巧妙之处，需要先简单地了解对称加密和非对称加密的区别：
对称加密只有一个密钥，加密和解密都用这个密钥；
非对称加密有公钥和私钥，私钥加密后的内容只有公钥才能解密，公钥加密的内容只有私钥才能解密。
为了提高安全性，我们常用的做法是使用对称加密的手段加密数据。可是只使用对称加密的话，双方通信的开始总会以明文的方式传输密钥。那么从一开始这个密钥就泄露了，谈不上什么安全。所以
TLS/SSL 在握手的阶段，结合非对称加密的手段，保证只有通信双方才知道对称加密的密钥。大概的流程如下：
https是运行在TLS/SSL之上的HTTP，与普通的HTTP相比，在数据传输的安全性上有很大的提升。要了解它的安全性的巧妙之处，
HTTPS
就是HTTP协议添加了一层SSL协议加密的处理，SSL证书就是遵守SSL协议，由受信任的数字证书颁发机构CA,在验证服务器身份后颁发，这是需要花钱滴，签发后的证书作为公钥一般放在服务器的根目录下的，便于客户端请求返回给客户端，私钥在服务器的内部中心保存，用于解密公钥。
HTTPS客户端和服务器交互过程：
1.客户端发送请求，服务器返回公钥给客户端；
2.客户端生产对称加密秘钥，用公钥对其进行加密后，返回给服务器
3.服务器收到后，利用私钥解开后得带对称加密秘钥，保存
4.之后的交互都使用对称加密后的数据进行交互
遇到是CA机构颁发的正经证书，我们直接可以用AFNetworking 直接请求就OK，它内部帮我们封装好了https的请求方式，
manager.securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey];
简单来说，就是你本可以修改AFN这个设来允许客户端接受服务器的任何证书，但是这么做有个问题，就是你无法验证证书是你的服务器后端的证书，给中间人攻击，即通过重定向路由来分析伪造你的服务器端打开了大门。
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy defaultPolicy];securityPolicy.allowInvalidCertificates =YES;
解决方法：AFNetworking
是运行内嵌证书的，通过内嵌证书，AFNetworking就通过对比服务器端证书，内嵌证书，站点域名是否一直来验证连接的服务器是否正确，由于CA证书是通过站点域名进行验证的，如果你的服务器后端有绑定的域名，这是最方便的。将你的服务器端证书，如果是pem格式的，用下面的命令转成cer格式。
openssl x509 -in <你的服务器证书>.pem -outform der -out server.cer
然后将生成的server.cer文件，如果有自建ca，再加上ca的cer格式证书，引入到app的bundle里，AFNetworking在
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy AFSSLPinningModeCertificate];
或者
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy AFSSLPinningModePublicKey];
会自动扫描bundle中.cer的文件，并引入，这样就可以通过自签证书来验证服务器唯一性了。
AFSecurityPolicy分三种验证模式：
AFSSLPinningModeNone
这个模式表示不做SSL pinning，
只跟浏览器一样在系统的信任机构列表里验证服务端返回的证书。若证书是信任机构签发的就会通过，若是自己服务器生成的证书就不会通过。
AFSSLPinningModeCertificate
这个模式表示用证书绑定方式验证证书，需要客户端保存有服务端的证书拷贝，这里验证分两步，第一步验证证书的域名有效期等信息，第二步是对比服务端返回的证书跟客户端返回的是否一致。
AFSSLPinningModePublicKey
这个模式同样是用证书绑定方式验证，客户端要有服务端的证书拷贝，
只是验证时只验证证书里的公钥，不验证证书的有效期等信息。只要公钥是正确的，就能保证通信不会被窃听，因为中间人没有私钥，无法解开通过公钥加密的数据。
