预备知识：数字签名 & 数字证书

数字签名和数字证书是什么？——阮一峰 (opens new window)

iOS证书签名原理分析

几个概念

• Apple ID:即Product ID，用于标识一个或者一组App。应该和Xcode中的Bundle Identifier是一致（Explicit）的或匹配（Wildcard）的。apple id字符串通常以反域名（reverse-domain-name）格式的Company Identifier（Company ID）作为前缀（Prefix/Seed），一般不超过255个ASCII字符。
• Device：运行iOS系统用于开发调试App的设备。每台Apple设备使用UDID来唯一标识。

iOS设备连接Mac后，可通过iTunes->Summary或者Xcode->Window->Devices获取iPhone的UDID（identifier）。

Apple Member Center网站个人账号下的Devices中包含了注册过的所有可用于开发和测试的设备，普通个人开发账号每年累计最多只能注册100个设备。

数字证书 互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。数字证书还有一个重要的特征就是时效性：只在特定的时间段内有效。某一认证领域内的根证书是CA认证中心（证书授权中心Certificate Authority）给自己颁发的证书，是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。

iOS证书 用来证明iOS App内容（executable code）的合法性和完整性的数字证书。对于想安装到真机或发布到AppStore的应用程序（App），只有经过签名验证（Signature Validated）才能确保来源可信，并且保证App内容是完整、未经篡改的。

iOS证书分为两类：Development和Production（Distribution）。

Development证书用来开发和调试应用程序 Adevelopment certificateidentifies you, as a team member, in a development provisioning profile that allows apps signed by you tolaunchon devices.

Production主要用来分发应用程序（根据证书种类有不同作用） Adistribution certificateidentifies your team or organization in a distribution provisioning profile and allows you tosubmityour app to the store. Only a team agent or an admin can create a distribution certificate.

证书签名原理分析

为什么要采用证书签名？

苹果为了控制每一个安装在苹果手机上的APP都是经过苹果官方认证的，于是就采用了签名机制。

从App Store安装APP

苹果官方生成一对公私钥，在苹果手机里面内置一个公钥，私钥由苹果后台保存，我们传App上AppStore时，苹果后台用私钥对App数据值的MD5值进行签名，iOS系统下载这个App后，用公钥验证这个签名，若签名正确，这个App肯定由苹果后台认证的，并且没有被修改过，也就达到了苹果的需求：保证安装的每一个App都是经过苹果认证允许的。

其他方式安装app

在实际工作当中，我们还有一些其他的方式把APP安装到手机上：

开发App时可以直接把开发中的应用安装进手机调试；

In-House企业内部分发，可以直接安装企业证书签名后的App;

AD-Hoc相当于企业分发的限制版，限制安装设备数量，较少用。

其基本流程如下：

• 1）在Mac上生成一对公私钥，这里称公钥M，私钥M。
• 2）苹果自己有固定的一对公私钥，跟上面AppStore例子一样，私钥在苹果后台，公钥内置在每个iOS设备上，这里称为公钥A，私钥A。
• 3）把公钥M上传到苹果后台，用苹果后台里的私钥A去签名公钥M。得到一份数据包含了公钥M以及其签名（也就是公钥的HASH值），把这份数据称为证书。
• 4）在开发时，编译完一个App后，用本地的私钥M对这个App进行签名，同时把第三步得到的证书一起打包进App里，安装到手机。
• 5）在安装时，iOS系统取得证书，通过系统内置的公钥A，去验证证书的数字签名是否正确。 验证证书确保公钥M是苹果认证过的，再用公钥M去验证App的签名，这里就间接验证了这个App的安装行为是否经过苹果官方允许

上述流程只解决了上面第一个需求，也就是需要经过苹果允许才可以安装，还未解决第二个避免被滥用的问题。怎么解决呢？苹果加了两个限制，一是限制在苹果后台注册过的设备才可以安装；二是限制签名只能针对某一个具体的App。

那么它到底是怎么添加这两个限制的呢？在上述第三步，苹果用私钥A签名我们的本地公钥M时，实际上除了签名本地公钥M外，还可以加上无限多数据，这些数据都可以保证是经过苹果官方认证的，不会有被篡改的可能。

可以把允许安装的设备ID列表和App对应的AppID等数据，都在第三步这里跟公钥M一起组成证书，再用苹果私钥A对这个证书签名。在最后第5步验证时就可以拿到设备ID列表，判断当前设备是否符合要求。根据数字签名的原理，只要数字签名通过验证，第5步这里的设备IDs/AppID/公钥M就都是经过苹果认证的，无法被修改，苹果就可以限制可安装的设备和APP，避免滥用。

到这里这个证书已经变得很复杂了，有很多额外信息，实际上除了设备ID/AppID，还有其他信息也需要在这里用苹果签名，像App里iCloud、push、后台运行 等权限苹果都想控制，苹果把这些权限开关统称为Entitlements，它也需要通过签名去授权。

实际上一个证书本来就有规定的格式规范，上面我们把各种额外的信息塞入证书里是不合适的，于是苹果另外搞了一个东西，叫Provisioning Profile，一个Provisioning Profile里就包含了证书以及上述提到的所有额外信息，以及所有信息的签名。 最终流程如下：

上面的步骤对应到我们平常具体的操作和概念是这样的：

• 第1步对应的是keychain里的“从证书颁发机构请求证书”，这里就本地生成了一对公私钥，保存的CertificateSigningRequest就是公钥，私钥保存在本地电脑里。
• 第2步苹果自己处理，我们不用管。
• 第3步对应把CertificateSigningRequest传到苹果后台生成证书，并下载到本地。这时本地有两个证书，一个是第1步生成的，一个是这里下载回来的，keychain会把这两个证书关联起来，因为它们的公私钥是对应的，在Xcode选择下载回来的证书的时，实际上会找到keychain里面对应的私钥去签名。这里私钥只有生成它的这台Mac才有，如果别的Mac也要编译签名这个App，把私钥导出给其他Mac使用，在keychain里面导出私钥，就会存成.p12文件，其他Mac打开后就导入私钥。
• 第4步都是在苹果网站上操作，配置AppID、权限、设备等，最后下载 Provisioning Profile文件。
• 第5步Xcode会通过第3步下载回来的证书(存着本地公钥)，在本地找到对应的私钥(第1步生成的)，用本地私钥去签名App，并把Provisioning Profile文件命名为embedded.mobileprovision一起打包进去。这里对App的签名数据保存分为两部分，Mach-O可执行文件会把签名直接写入这个文件里，其他资源文件则会保存在_CodeSignature目录下。
• 第6、7步的打包和验证都是 Xcode 和 iOS 系统自动做的事。

回顾ios几个常见概念

Entitlements：包含了App权限开关列表。 CertificateSigningRequest：本地公钥。 .p12：本地私钥，可以导入到其他电脑。 Provisioning Profile：包含了 证书/Entitlements 等数据，并由苹果后台私钥签名的数据包。