前言
最近在负责ios的项目，被各种证书跟签名概念弄的一脸懵逼，而且之前也没怎么接触过IOS的测试，显的更加小白了，因此想把这块知识弥补下；
签名
目的
先来看看苹果的签名机制是为了做什么。
在 iOS 出来之前，在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的，软件随便从哪里下载都能运行，导致平台对第三方软件难以控制，盗版流行。
苹果希望解决这样的问题，在 iOS 平台对第三方 APP 有绝对的控制权，一定要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的，怎样保证呢？就是通过签名机制。
对称加密
一般说的签名指的就是数字签名，它是基于非对称加密算法实现的；
什么是非对称加密？
非对称加密是相对于对称加密而言的；
但无论是哪种方式的加密，目的都是为了保护被加密的内容；
度娘关于对称加密的解释：
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，
这种加密方法称为对称加密，也称为单密钥加密。
嗯，看不懂吧？懵逼吧？没关系，接着看~
jb有一封信,只想给自己跟YY看，于是JB为这封信设置了密码（加密），然后寄给YY，YY只要知道信的密码就可以查看其中的内容（解密），别人即使拿到信想看，但没有密码（密钥），也无法查看里面的内容；
所谓的对称就是加密和解密的过程使用的是相同的密钥；
非对称加密
与对称加密不同,非对称加密算法的加密和解密使用不同的两个密钥.这两个密钥就是我们经常听到的公开密钥(公钥)和私有密钥(私钥);
公钥和私钥的关系是:
公钥和私钥一般成对出现；
如果你的消息使用公钥加密,那么需要该公钥对应的私钥才能解密;
如果你的消息使用私钥加密,那么需要该私钥对应的公钥才能解密；
非对称加密的作用是:
保护消息内容, 并且让消息接收方确定发送方的身份；
不懂？接着看吧~
还是上面的例子，使用对称加密的问题在于，一旦密钥在传输过程中泄露了，保密性就荡然无存了；
既然对称加密的安全性会低一些，那就采用非对称加密，这样，JB 跟 YY就需要各自持有一对属于自己的公钥和密钥；
JB写的信只想给YY看，那么YY跟别人会有什么不一样的特质呢？那就是YY拥有只有他自己知道的密钥！
如果JB使用YY的公钥加密，那么就只有YY的密钥才能解密，这样就能达到只让YY看的目的；
这里需要说明下，公钥是公开给别人开的哦；
那有一种情况，既然YY的公钥是公开的，假如有一个SB想冒充JB，使用YY的公钥加密然后给YY写一封信；
JB为了避免这种情况的发生，把信的内容用JB自己的密钥进行加密，YY收到信后，使用JB的公钥解密（只有JB的公钥才能解开使用JB私钥加密的内容），如果可以解开，那么YY就知道这封信的确是JB发的，这是为了确定消息发送方的份；
可能文字看上去会懵逼，因此就花了个流程图，便于理解：
上面这个，就是非对称加密，回到IOS本身，当我们想把写好的IOS程序运行到真机时，会使用到这种非对称加密的方式进行认证，从而确保程序的来源是可信且安全的~
数字签名&证书
那数字签名又是什么？
简单的话，数字签名的作用是对某一份数据打了标记，表示认这份数据，相当于签了个名，然后再发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过；
这里的话，直接贴一峰大神的翻译文章，方便了解；
链接如下：数字签名是什么
1)鲍勃有两把钥匙，一把是公钥，另一把是私钥。
2)鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
3)苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
4)鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
5)鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。
6)然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
7)鲍勃将这个签名，附在信件下面，一起发给苏珊。
8)苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
9)苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
10)复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
11)后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
12)鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
13)苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
正文看完下来，对数字签名以及数字证书有了初步认识了= =
证书信息
科普
1）苹果开发者中心网站
2)开发者帐号的类型：
个人-$99（约688元/年）（调试证书最多只能有两个）
公司-$99（约688元/年）需要提供邓白氏编码，用于企业认证，可以进行团队开发管理
企业-$299，需要提供邓白氏编码，程序不能上架到AppStore（用于企业内部办公软件等）（调试证书最多有五个）
创建证书
1）添加证书
2）选择证书
- 开发证书（Development）：最多1个（20170425日只能生成一个了）
- 发布证书（Production）：最多3个
3）准备创建CSR文件
4）创建CSR文件01（打开钥匙串->证书助理->从证书颁发机构请求证书）
5）创建CSR文件02（填写电子邮件地址，常用名称，这两项都可以随便填，注意要把CSR文件存储到磁盘）
6）创建CSR文件
7）选择刚刚创建的CSR文件
8）创建证书完毕，下载证书
iOS 的签名证书机制
AppStore
从 AppStore 下载的应用验证流程非常简单，苹果官方身材一对公私钥，在ios里内置一个公钥，私钥由苹果后台保存，当传 App 上 AppStore 时，苹果后台用私钥对 APP 数据进行签名，iOS 系统下载这个 APP 后，用公钥验证这个签名，若签名正确，这个 APP 肯定是由苹果后台认证的，并且没有被修改过，也就达到了苹果的需求：保证安装的每一个 APP 都是经过苹果官方允许的。
Xcode Build
那日常开发中，总没可能每次都提交到App Store的，所以在本地调试时，设备会把对APP的验证，改成对开发者的验证；
此处的开发者账号，就是在 Apple Developer Center 中所申请的开发者账号，一旦信任之后，每次 build 的时候，iOS 设备就将验证该开发者身份，而不是验证你 build 的 App。如此一来，便省去了应用包上传、下载的过程。我们知道，验证 App 是通过签名机制，来确定安装包来源的，而此处的验证开发者身份，又是怎样的机制呢？
验证开发者
首先，iOS 设备需要验证你的开发者身份，这是基于 macOS 的一种证书策略，如果打开钥匙串访问，选中证书，我们可以看到这样的一堆东西：
在这里能看到各种各样的证书；
当在 Xcode 添加自己的账号后，并在项目中将 Team 选择为自己的开发者账号后，钥匙串中就多出了这么一个东西：
这份密钥在生成的时候，Xcode 将密钥的公钥部分上传至 Apple 服务器，由 Apple 进行签名生成证书，最后返回到本地，而私钥，则会在 Xcode 本地构建安装时，用来为 App 安装包签名。最后，Xcode 会将签名后的安装包和本地证书打包都放到 iOS 设备中，iOS 设备接着使用 Apple 公钥来解密证书，拿到本地公钥，接着用本地公钥去解密 App 。
其实，也就2个事情：
- iOS 设备用 Apple 公钥解密证书，所拿到的本地证书，必定是经过 Apple 服务器签名的，也就是说，这里保证了开发者是经过苹果认证的。
- 上一步拿到的公钥，用于解密 App 签名，若解密成功且验证通过，证明该 App 确实是由该开发者构建的，也就保证了 App 的安全性。
上述的流程唯一问题是，这个密钥是在本地生成的，如果更换了电脑，本地的密钥对就会改变。这时候，你需要将旧 mac 上的证书导出，并安装到新的电脑上。
小结
本文主要介绍了签名跟证书的只是，包括对称加密跟非对称加密，以及数字证书相关信息，并且介绍了App Store跟xcode的证书逻辑，从大致上对IOS证书这块起到扫盲的作用，具体细节就不再深入了，大致就先这样吧，后续需要再另写一篇~
谢谢大家~
