因为2017年开始，苹果官方要求必须支持Https，ATS允许http加载 策略将被关闭。所以最近许多小伙伴应该都在为适配而忙着搜集资料。最开始看一些关于证书的东西，自己也是一脸懵逼。看了好几遍，才大致懂了一点点。自己还去创建了证书，搭建了tomcat进行调试。虽然忙了半天效果不显著，但是略有收获，会进行tomcat简单配置环境了（窃喜：只要有进步都是好的）。不扯了，进入正题。
首先，一般小伙伴刚看到要适配的时候，一般会去查证书相关信息，其实先不用管证书问题，等后台配置好了，给你个证书就行了（我可没有甩锅给后台，主要自己要先把客户端配置好，联调最主要，也耗费时间，有时间了再详细了解证书）。
第一种最简单方式，后台配置完成后，客户端直接把请求改为https，ATS中Allow Arbitrary Loads改为NO,一行代码没有修改，惊奇的发现，居然可以请求了。是不是很窃喜，暗自感叹So easy! 小伙子高兴的太早了。这种方式我理解为挂着https的旗帜，实际还是http。别人还是可以随意的看你请求数据和返回数据。可能有的小伙伴这时候有疑问了，用charles抓包时候发现，是没办法抓到数据，显示的是unkown,看返回数据是乱码,猿（楼主）又在瞎说了。
这是因为你没有启用SSL 代理。右击你的请求url，就会弹出选择框，点击Enable SSL Proxying。
至于这块charles的配置，在此我就不详细解释了，有时间了再补充一下。自己查询一下资料,主要就是手机添加charles ssl证书，然后就可以看到跟请求http 一样可以抓取数据了，所以楼主说只是挂了https 的牌子，没有做具体的事情。至于苹果是否能够审核通过，我也就不清楚了，反正楼主不当第一个吃螃蟹的人（因为程序员要降低被拒风险）。
第二种方式，脚踏实地，一步一个脚印。先上代码：
+ (AFSecurityPolicy*)customSecurityPolicy
{
//先导入证书
NSString *cerPath = [[NSBundle mainBundle] pathForResource:certificate ofType:@"cer"];//证书的路径
NSData *certData = [NSData dataWithContentsOfFile:cerPath];
// AFSSLPinningModeCertificate 使用证书验证模式
//AFSSLPinningModeNone: 代表客户端无条件地信任服务器端返回的证书。
//AFSSLPinningModePublicKey: 代表客户端会将服务器端返回的证书与本地保存的证书中，PublicKey的部分进行校验；如果正确，才继续进行。
//AFSSLPinningModeCertificate: 代表客户端会将服务器端返回的证书和本地保存的证书中的所有内容，包括PublicKey和证书部分，全部进行校验；如果正确，才继续进行。
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
// allowInvalidCertificates 是否允许无效证书（也就是自建的证书），默认为NO
// 如果是需要验证自建证书，需要设置为YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要验证域名，默认为YES；
//假如证书的域名与你请求的域名不一致，需把该项设置为NO；如设成NO的话，即服务器使用其他可信任机构颁发的证书，也可以建立连接，这个非常危险，建议打开。
//置为NO，主要用于这种情况：客户端请求的是子域名，而证书上的是另外一个域名。因为SSL证书上的域名是独立的，假如证书上注册的域名是www.google.com，那么mail.google.com是无法验证通过的；当然，有钱可以注册通配符的域名*.google.com，但这个还是比较贵的。
//如置为NO，建议自己添加对应域名的校验逻辑。
//对应域名的校验我认为应该在url中去逻辑判断。--》冯龙腾写
securityPolicy.validatesDomainName = NO;
if (certData) {
securityPolicy.pinnedCertificates = [NSSet setWithObjects:certData, nil];
}
return securityPolicy;
}
这部分代码是配置验证策略，摘自冯龙腾（虽然不知道哪位大神，还是要谢谢这么详细的注释。）然后把返回的securityPolicy赋值给AFHTTPSessionManager的securityPolicy属性。有时间的朋友，可以看看AFN源码了解一下底层验证策略。其实第一种方式，只添加了https请求，然后什么代码也没添加的方式，采取的是AFN 默认验证策略
[AFSecurityPolicy defaultPolicy];
所以不用惊讶为啥能走的通，只不过采取的验证方式不同。这时候就可以跟后台要证书，进行联调了。
一般只要证书没有问题，并且后台支持了https，走通网络请求，应该问题不大。最开始我们使用的是自建证书，后台使用keytool生成证书，当时前端和后台使用的是同一个证书，看AFN源码过程中，发现验证过程如果证书一致，也是可以正常请求的。但是不是CA证书，继续改进，使用openssl创建了自建的CA证书。自建CA证书和授权CA证书，最大的区别，也是最简单的区别，就是你用浏览器访问时候，自建证书会显示不是私密链接，点击高级，继续进行访问，提示你不安全信息。
而授权CA证书，则可以直接正常访问
使用自建证书的时候，允许使用自建证书设置为YES,
securityPolicy.allowInvalidCertificates = YES;
AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeNone];
当时这种情况我是没有走通的，难道是没有授权允许继续访问按钮？这就尴尬了，没太多的时间去管这个了，跟后台大哥说，咱还是用授权的CA证书吧，后台大哥说，授权CA证书得money啊，一脸的不情愿，好在一不小心看到阿里有个可以申请免费的CA证书，当时我是泪流满面。证书搞定，然后联调一切正常。
这还没完，要记得把自己用的第三方，友盟统计，shareSDK，推送，热部署JSPatch等等，更新到支持Https，如果有不支持https 请求的，要加入白名单（不知道苹果审核允许不允许，但是目前没想到好的方式）。还有网页请求，也要注意一下。配置结束以后，用charles 抓包，查看一下有没有请求失败的，如果有，核查哪一部分的问题。
最后提醒一下，授权证书是有过期时间的，要做好更新证书策略，策略问题，目前我们已经处理完了，每个公司不同，自己可以想一个比较完善的策略。希望大家的APP能够顺利上架。如果有理解不对的地方，请指出，不断学习进步的小码农。
