iOS 开发者证书的底层原理

在日常iOS开发中，都会遇到各种的证书、签名有关的问题。如果你只是一个人开发，你拥有开发者最高权限，参考网上的教程可以轻松的解决证书、签证等问题开发；但是如果你是在一个Team中，签名、证书就会出现各种各样的问题，影响你的调试、打包和上传，而开发者证书的底层原理你花一些时间去深入的理解，让你在遇到证书相关的问题游刃有余。

一、基本概念

在计算机世界里Apple开发者证书并不是独立于任何系统单独存在的，而是由证书颁发机构（CA，Certificate Authority）即颁发数字证书的机构认证的一个证书颁发机构。

CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书。在SET交易中，CA不仅对持卡人、商户发放证书，还要对获款的银行、网关发放证书。

证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。证书的内容包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。

总结上边的内容，简单来讲，证书底层原理就涉及两个关键概念：

数字签名
数字证书

数字签名

数字签名（又称公钥数字签名） 是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

在数字签名技术中，有两种行为：

签名生成
签名验证

在数字签名技术中，有常用的两种实现算法：

1.有哈希算法的数字签名与验证

哈希函数是一种“压缩函数”，利用哈希函数可以把任意长度的输入经由散列函数算法变换成固定长度的输出，该输出的哈希值就是消息摘要，也称数字摘要。在正式的数字签名中，发送方首先对发送文件采用哈希算法，得到一个固定长度的消息摘要( Message Digest)；再用自己的私钥( Secret key，SK)对消息摘要进行签名，形成发送方的数字签名。数字签名将作为队件和原文一起发送给接收方；接收方首先用发送方的公钥对数字签名进行解密得到发送方的数字摘要，然后用相同的哈希函数对原文进行哈希计算，得到一个新的消息摘要，最后将消息摘要与收到的消息摘要做比较。

2.基于非对称密钥加密体制的数字签名与验证

发送方首先将原文用自己的私钥加密得到数字签名，然后将原文和数字签名一起发送给接收方。接收方用发送方的公钥对数字签名进行解密，最后与原文进行比较，数字签名采用了规范化的程序和科学化的方法，用于鉴定签名人的身份以及对一项电子数据内容的认可。使用数字签名技术能够验证文件的原文在传输过程中有无变动，确保传输电子文件的完整性、真实性和不可抵赖性。

![非对称RSA算法![](https://img-blog.csdnimg.cn/20200414142607443.jpeg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Z1dHVyZV9PbmU=,size_16,color_FFFFFF,t_70)

数字证书

数字证书（Digital Certificate） 是一种相当于现实世界中身份证的功能在数字信息领域中的实现。数字证书包含了个人或机构的身份信息及其公钥，因此也称为公钥证书（Public-Key Certificate，PKC）。

首先去KeyChain（钥匙串访问），查看一下安装的开发者证书的信息。
根据证书颁发的机构Apple Worldwide Developer Relations Certification Authority在钥匙串中找到证书如下的证书关系：

根证书 Apple Root Certificate Authority 是在 MacOS 操作系统安装时内置的，是 Apple Root CA 自行颁发的。

中间证书 Apple World Developer Relations Certificate Authority （实际文件为 AppleWWDRCA.cer）是在Xcode 安装时内置的，是 Apple Root CA 颁发的。虽然 AppleWWDRCA.cer 是中间证书，但是对于 iOS 开发分类来说，它就是开发根证书。

Mac电脑上开发者的证书的关系：

Apple Root CA（Apple Certification Authority）：根证书
- Apple Worldwide Developer Relations Certification Authority：中间证书
  - iPhone Developer: Jack Wangle(XXXXXXX)：子证书

二、Certificates 的申请

Certificate是用来给应用程序签名的，只有经过签名的应用程序才能保证他的来源是可信任的，并且代码是完整的、未经修改的。证书的后缀为.cer

在我们申请证书前，需要先申请一个CSR（即Certificate Signing Request）文件，此过程实际上是生成一对密钥（即公钥和私钥），这对密钥将保存在开发者Mac电脑的Keychain（即钥匙串访问）中，CSR文件中则包含公钥。具体操作如下：

证书类型有很多种，这里简单介绍一下常见的：

iOS App Development（即开发证书），用于开发和真机调试app
iOS Distribution (App Store and Ad Hoc)（即分发证书），用于苹果应用市场（App Store）和内部分发渠道（Ad Hoc）
APNS（Apple Push Notification Service，即苹果推送证书），用于推送通知到app。
- 与开发证书和分发证书不同的是，APNS与App ID有关。
- APNS有两种证书，分别是用于开发环境的 iOS Apple Push Notification service SSL (Sandbox)，以及用于生产环境的 Apple Push Notification service SSL (Sandbox & Production)。如果你的app有推送服务，这两种推送证书都是需要创建的

1.打开KeyChain（钥匙串访问）—>证书助手---->从证书颁发机构请求证书…

2.保存从CA请求的证书（CSR文件）

2.1保存到本地的证书文件（CSR文件）

2.2从KeyChain中可以生成的一对private Key 和 Public Key

3.创建开发者证书，上传需要的CSR文件，由Apple CA进行签名生成开发者证书。

4.下载生成的证书到Mac本地，双击安装即可。

介绍：

p12文件

p12文件更确切的说：p12证书，因为其本身就是一个加密的证书，后缀为.p12。开发者将CSR文件发给苹果服务器，由此苹果服务器会生成Certificate文件（含公钥），接着开发者将其下载到本地，再导入钥匙串中后，就可以从钥匙串中导出p12证书。显然，p12文件里面有匹配的公钥和私钥。

三、创建 Identifiers & Device & Profiles

1.Identifiers创建App ID

App ID用于标识一个或者一组App。主要有两种：

Explicit App ID：是app的唯一标识符，它由苹果为开发者创建的team id和app的bundle id组成。每个app都会有且仅有一个明确的Explicit App ID。
Wildcard App ID：即通配符App ID，用于标识一组app，以*结束，如com.company.*标识以com.company开头的所有应用程序。

2.Device创建

Devices中包含了苹果开发者账号中所有可用于开发和测试的设备，每台设备使用UDID来唯一标识。

3.Provisioning Profile(描述文件)创建

一个描述文件包含了App ID、Certificate、Device，其后缀为.mobileprovision。常用的有：

iOS App Development，用于开发时的真机调试，包含App ID、证书和设备
Ad Hoc，用于分发时的真机调试，同样包含App ID、证书和设备
App Store，用于分发到苹果应用市场，包含App ID和证书，与设备无关，且所有能访问App Store的苹果设备均可下载安装app。

描述文件的作用主要是：

限制只有在苹果后台注册过的设备才可以安装
限制签名只能针对某一个具体的App

描述文件中还包含Entitlements（权限信息），权限信息指明了app使用的苹果服务，如iCloud权限、推送、苹果内购等。

1.选择Provisioning Profile的类型

2.Provisioning Profile选择对应的Identity的Apple ID

3.选择对应的证书文件

4.选择Device设备

5.填写创建的Provisioning Profile文件的名字

6.下载Profile文件

四、iOS签名的原理

1.iOS证书申请的基本原理

开发者在本地生成密钥对，并提供开发者的身份信息。
将密钥对中的公钥、身份信息发送给 CA。
CA 使用 CA 私钥对开发者的公钥、身份信息进行签名。
CA 将开发者的公钥、身份信息、签名组装成证书以供下载。

2.iOS证书申请的基本原理

解释说明：

1.苹果官方有多对密钥，即私钥和公钥

2.生成CRS文件时，证书助手使用Apple Worldwide Developer Relations Certification Authority证书中的公钥对生成的一对密钥（公钥M、私钥M）中的公钥M以及对应的电脑上的开发认证信息发送给苹果服务器。（Mac电脑和苹果之间存在的一对钥匙串在图上并没有显示）

3.创建证书之前，生成CRS文件是，创建的在Mac电脑上的密钥（记作：密钥M：公钥M、私钥M）

4.苹果和IPhone手机之间存在一对密钥（记作：密钥A：公钥A、私钥A）

下方详细分析一下iOS的签名原理（签名和验证）：

1.创建证书前的准备工作，首先通过钥匙串申请一个CRS文件，同时生成一对非对称加密密钥，也就是如上图的：私钥M 和公钥M，会把公钥M 和 Mac上的证书信息（Apple Worldwide Developer Relations Certification Authority）放在CSR文件中

2.上传CSR文件发送给苹果服务器，用于申请证书，苹果服务器使用苹果私钥A 对接收到的公钥M + 信息进行签名。生成Certificate文件（文件后缀名：.cer），并下载到本地安装。并创建App对应的 Devices 、App ID（包含Entitlements）。

3.在创建 Provisioning Profile 中， Provisioning Profile 分别对Certificate 、Devices 、App ID（包含Entitlements）一起的数据用私钥A进行签名，生成Provisioning Profile（即描述文件），下载安装到Mac电脑。

4.iOS项目编译完之后生成.app文件，在.app文件中含有Provisioning Profile描述文件（embedded.moblieprovision 描述文件） + 安装包 + 其他信息。

iOS安装包 .ipa文件解压之后的文件目录：（最终安装包.app和编译后的.app一致）

.ipa 解压之后的文件目录

XCode先使用私钥M对.app进行签名，然后，把.app和描述文件一起压缩成安装包.ipa文件。是对资源文件的签名，生成的签名文件名为CodeResources，存放在.app目录下的_CodeSignature文件夹中。
5.XCode准备把安装包安装在苹果设备（如iPhone）上。

6.iPhone对安装包进行验证，即用公钥A 验证描述文件中的签名。验证通过则说明描述文件里的数据是苹果授权的。

7.当第【6】步验证通过后，再用公钥A验证证书中的签名。验证通过则说明公钥M是安全可信任的。

8.第【7】步验证通过后，就可以取出描述文件里的数据做各种验证，包括用公钥M验证App签名，验证iPhone是否在设备列表中，App ID是否对得上，使用的权限是否跟Entitlements对应等。当这些全部验证通过，iPhone就可以安装app了。

以上就是iOS签名的流程，分析了苹果用了两对非对称加密密钥，进行的是双重验证，基本保证了XCode真机调试的安全性，确保app的安装行为是受到苹果管控的。

总结

非对称加密贯穿于 iOS 开发之中。当我们在开发中遇到签名、证书相关的问题时，我们只要结合证书幕后的原理，很容易就能找到解决办法。