iOS中的Code Signing体系非常复杂，对新手非常不友好，虽然目前网上已经存在大量文章对此进行比较透彻的分析，最核心的部分已经讲解得非常清楚，我阅读了这些文章后，确实从中学习到不少知识，但我始终还是对Code Signing体系中很多相关的地方有着疑惑，于是决定认真地探究一番。本文会引用一些比较好的文章中的内容和图片，加上一些我个人的理解进行分析，有些内容本文不再重复，有需要的请阅读本文最后的参考文章。

概念

公开密钥加密、数字签名、证书这些通用的基本概念这里不再多说，主要提一下iOS上特有的东西

.certSigningRequest

点击mac OS的钥匙串访问里的 证书助理 -> 从证书颁发机构请求证书，最后会创建出一个.certSigningRequest文件，其实这个过程就是创建了一对公私钥

其中.certSigningRequest文件保存着
- 申请者信息申请者的公钥
- 摘要算法
- 公钥加密算法
私钥保存在 keychain 中

证书

AppleWWDRCA

iOS 以及 mac OS（在安装 Xcode 时）将自动安装 AppleWWDRCA.cer 这个中间证书（Intermediate Certificates），它实际上就是 iOS（开发）证书的证书，即根证书（Apple Root Certificate）。

iOS App Development

iOS的开发证书，在开发阶段进行真机测试时需要用到的证书。可以在苹果开发网站上手动创建，需要上传.certSigningRequest文件；或者使用Xcode自动创建。

iOS Distribution

iOS的发布证书，可以用于进行 Ad Hoc 测试、打包上传到 App Store 或者打包成 Enterprisee（In-House）类型供企业内部使用。可以在苹果开发网站上手动创建，需要上传.certSigningRequest文件；或者使用Xcode自动创建。

.p12

在mac OS的钥匙串访问里选择一张证书，右击该证书，选择导出"xxxxx"，然后设置密码，可以导出该证书对应的.p12文件。.p12文件包含个人信息、公钥和私钥，也就是证书 + 私钥。iOS类型的每种证书同时存在数量有限制，而证书是依靠mac OS上的.certSigningRequest文件创建的，所以正常情况下，每种类型的证书只能在有限的Mac电脑上使用，如果需要在更多不同的Mac电脑上进行App开发、测试、签名，可以导出对应.p12文件代替证书来使用。

Provisioning Profile

Provisioning Profile的文件格式为.mobileprovision，里面包含着

可以使用的证书
App ID，由 TeamID 和 BundleID 组合而成，类似于 A1B2C3D4.com.domain.appName 形式
可安装该App的设备列表的UDID
Entitlements，授权文件，列出了App可以进行哪些行为
以上信息的签名

在苹果开发网站上手动创建，或者使用Xcode自动创建。

.ipa

.ipa文件是iOS上的App安装文件，其实它只是一个压缩包，等同于.zip格式，用mac OS自带的归档实用工具可以直接对它解压，可以看到里面的内容

用于上传App Store的.ipa文件

App Store下载的.ipa文件

对比两种情况的.ipa文件，可以看出它里面最主要的是Payload文件夹，而Payload文件夹里面放的就是该App对应的.app文件

.app

右击.app文件，选择显示包内容，可以看到里面的内容

用于上传App Store的.app文件

从App Store下载的.app文件

可以看出.app文件主要包含四个部分：

Mach-O格式的二进制可执行文件，这个是一个App最重要的文件，我们编写的Objective-C、Swift代码都被编译在里面
资源文件，包括：.bundle文件，.framework文件，.dylib文件，.nib文件，图片文件，音视频文件，字体文件等所有项目用到的文件
CodeResources，签名信息
embedded.mobileprovision文件，或者entitlements文件
- 对于没有上传App Store的.app文件，里面会包含embedded.mobileprovision文件，没有entitlements文件
- App Store下载的.app文件，里面会包含.entitlements文件，没有embedded.mobileprovision文件

Code Signing

正常情况下（非越狱），所有App想要安装到iOS设备上，只有以下几种方法

非App Store
- 真机调试
- Ad-Hoc
- In-House
App Store

无论是哪一种方法，都需要先把iOS项目编译成.app文件，然后进行签名。按照惯例，需要分析一下Code Signing

非App Store

对于非App Store获得的.ipa文件，需要严格复杂的签名和验证流程

创建.certSigningRequest文件，这时候会生成一对公私钥，这里称为公钥L（L：Local），私钥L。.certSigningRequest文件保存着公钥L
iOS 以及 mac OS上的AppleWWDRCA.cer 证书保存的就是苹果的公钥A（A：Apple），而对应的私钥A则在苹果的后台
在苹果开发者网站上创建证书的时候，上传.certSigningRequest文件其实就是把公钥L传到苹果后台，用苹果后台里的私钥A去签名公钥L，得到对应的证书，把证书下载回来双击安装，会跟对应的私钥L绑定一起保存在keychain中
除了证书，还需要对应的Provisioning Profile。在苹果开发者网站上：
1. 设置App的Bundle ID
2. 设置可安装该App的设备UDID
3. 设置该App的权限
4. 设置可以使用的证书
5. 最后会使用私钥A把以上这些数据进行签名，组成一个Provisioning Profile，格式为.mobileprovision，下载回来双击安装，会保存在~/Library/MobileDevice/Provisioning Profiles中，文件名为它的UUID
当需要把一个App安装在iOS设备上时，都会先把iOS项目编译打包成.app文件，而打包成可安装在iOS设备上的.app文件的前提是，设置该App的Provisioning Profile，最后使用合法的证书对源代码编译后的各种文件进行签名，步骤如下：
1. 用mac OS里的公钥A验证Provisioning Profile，获取里面的信息
2. 用Provisioning Profile里面的信息验证App的Bundle ID是否对应，App的权限是否对应
3. 用公钥A验证Provisioning Profile里面的证书，再判断是否有其中一张证书在这台Mac电脑里
4. 如果上面的验证都通过了，则会从mac OS的keychain 中取出符合条件且最新创建的证书，拿到对应的私钥L
  1. 如果有.framework文件、.dylib文件、插件、watch目录下的extension，对它们分别进行签名
  2. 把Provisioning Profile改名为embedded.mobileprovision放在.app文件里面
  3. 使用私钥L对整个.app文件进行签名，得到签名信息CodeResources也放会在.app文件里面
5. 如果需要生成.ipa文件，则会把.app文件放在Payload文件夹里，把Payload文件夹和一些其他信息文件（非必要），一起压缩形成一个.ipa文件
把.ipa文件或者.app文件安装在iOS设备上时
1. 先使用iOS设备上的公钥A对.app文件里面的embedded.mobileprovision文件进行验证，获取里面的证书
2. 再使用公钥A对embedded.mobileprovision文件里面存在的证书进行验证，取出一张对应的证书，得到公钥L
3. 使用公钥L对.app里面所有签名信息进行验证，如果验证通过，证明该.app文件是完整合法，没有被篡改的
4. 获取embedded.mobileprovision文件里面的可安装该App的设备UDID列表，判断该iOS设备是否可以安装
5. 如果前面的验证都通过，则App会安装在iOS设备上

App Store

当需要在App Store发布App时，则先需要把.ipa文件上传到App Store。苹果会用一种非常简单的方式进行重新签名，这是因为在把.ipa文件上传到App Store之前，会先进行类似于上面步骤的一系列验证，只有通过验证才会上传成功，所以这已经进行过一次复杂的验证，代表苹果已经认同了这个.ipa文件，而用户又是从App Store下载的，所以也保证了.ipa文件来源是权威的，最后只需要在用户设备上进行简单的验证就可以

苹果用私钥A对.app文件里面需要签名的文件进行重新签名
用户下载App Store上面的.ipa文件进行安装时，用iOS设备上的公钥A对.app文件里所有签名信息进行验证，如果验证通过，则会安装在iOS设备上

重签名

在完全了解iOS中的Code Signing体系后，除了可以让你在日常开发中遇到证书、签名等问题的时候解决起来得心应手，还有一个重要的应用就是重签名。网上也有一大堆关于重签名的文章，大多数都只是说了怎么操作，但是很少会解释为什么要这样操作。接下来我会结合本文前面的内容详细分析重签名的原理。

原理

重签名顾名思义，就是把.ipa文件也就是.app文件进行重新签名。经过前面的分析，iOS的Code Signing体系是依靠两个文件来进行签名：证书和Provisioning Profile，它们是由苹果后台生成的，并且用私钥A进行签名，所以重签名的第一步就是需要准备有效合法、由苹果后台生成的证书和Provisioning Profile，它们必须是相对应并且没有被修改过的。需要注意的是，如果这证书不是由你的Mac电脑去请求生成的，是它无法跟它里面公钥L对应的私钥L绑定在一起，因为你的Mac电脑里根本没有对应的私钥L，所以这时候是需要它对应的.p12文件，安装.p12文件就会得到证书和对应的私钥L
签名的时候，会拿到Provisioning Profile里面的信息验证App的Bundle ID是否对应，App的权限是否对应，所以要把进行重签名的App的Bundle ID改成跟Provisioning Profile记录的一致。而App的权限则需要直接从Provisioning Profile中导出entitlements.plist文件，最后在重签名的时候使用
既然是对.app文件进行重签名，那么最后就是需要准备一个没有被加密的.app文件。在App Store下载.ipa文件里面的.app文件都是被加密，被加密的.app文件无法进行重签名
准备工作已经完成，现在就可以开始重签名，步骤其实是跟初次签名一样的。首先把准备好的Provisioning Profile改名为embedded.mobileprovision放在.app 文件中或者进行覆盖。使用准备好的证书，对.framework文件、.dylib文件、插件、watch目录下的extension分别进行签名，最后用证书和导出entitlements.plist文件再对整个.app文件签名
关于证书的类型和App的安装限制：既然进行了重签名，那么这个App可以安装的iOS设备就会受到使用的证书和Provisioning Profile的限制，所以一般会使用企业账号的发布证书和In House类型Provisioning Profile进行重签名，这样就可以使App安装在任何iOS设备上

步骤

准备合法完整的证书（或者.p12文件）和Provisioning Profile
准备一个已经脱壳的.app或者.ipa文件，其中Bundle ID要跟Provisioning Profile中的一致

// 在.app文件中，把Info.plist的Bundle ID改为 com.xxx.xxx
/usr/libexec/PlistBuddy -c 'Set :CFBundleIdentifier com.xxx.xxx' "Info.plist"

从Provisioning Profile提取entitlements

// 从embedded.mobileprovision文件中提取出entitlements.plist权限文件
security cms -D -i embedded.mobileprovision > temp.plist
/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' temp.plist > entitlements.plist

把Provisioning Profile改名为embedded.mobileprovision放在.app 文件中
使用准备好的证书，对.framework文件、.dylib文件、PlugIns目录里的.appex文件、Watch目录里的.app文件分别进行签名，最后用证书和导出entitlements.plist文件再对整个.app文件签名

// 查看可用的证书
security find-identity -v -p codesigning// 对.app内部的.framework文件、.dylib文件、PlugIns目录里的.appex文件、Watch目录里的.app文件分别进行签名
codesign -fs   证书ID   xxx.dylib// 对.app文件进行签名
codesign -fs   证书ID  --entitlements entitlements.plist xxx.app

查看新的签名信息

codesign -d -vv xxx.app

打包成.ipa文件

zip -r xxx.ipa Payload/

注意

正常情况下.app的Bundle ID要跟Provisioning Profile中的一致，但实际操作发现，就算Bundle ID不一致也可以正常安装使用，但应该存在一定的隐患，所以建议还是保持一致
重签名的时候，为了方便，可以直接把.app 文件里面的PlugIns目录、Watch目录都删除，一般情况下不会用到。但是为了项目的完整性，以防出错，最好把它们也保留。PlugIns目录的文件可以直接用证书分别对它们进行签名。而在微信里，Watch目录里面是一个.app文件，我不确定是不是所有App都是如此，以微信为例，对它进行签名前，需要进去打开内部的Info.plist文件，把其中两个值进行修改，分别是：
- WKCompanionAppBundleIdentifier，这个key对应的值指定了Watch目录的.app文件用于哪个App，在微信中为com.tencent.xin，可以看出是跟微信的Bundle ID一样，所以需要把它改为跟Provisioning Profile中的一致
- Bundle identifier，这个key对应的值表示Watch目录的.app文件自己的Bundle ID，在微信中为com.tencent.xin.watchapp，可以看出它的前缀是微信的Bundle ID，所以需要把它的前缀改为跟Provisioning Profile中的一致，后面的部分保持不变就可以
- 完成上面的修改后就可以用证书对Watch目录里面的.app文件签名

结语

以上就是我个人对Code Signing体系的观察和分析，大家可以看到相关的东西很多，需要注意的地方也很多，我尽量地把这些细节都总结出来，而这方面官方文档确实没有写得很详尽（或许是我没找到），所以很难把所有特性和表现都完全正确地总结出来，如果大家有发现文章中什么问题，请在评论中指出，我会及时验证、修改。

参考文章

黑幕背后的 Code Signing

iOS Provisioning Profile(Certificate)与Code Signing详解

iOS之从创建（Development、Distribution）证书到发布

iOS App 签名的原理

作者：Dan1els
链接：https://www.jianshu.com/p/a8971e09bea6
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

iOS 的 (签名验签)Code Signing 体系

概念

.certSigningRequest

证书

AppleWWDRCA

iOS App Development

iOS Distribution

.p12

Provisioning Profile

.ipa

.app

Code Signing

非App Store

App Store

更多相关

苹果开发者帐号体系

免费账号的限制：

Automatic signing

Xcode对Provisioning Profile的验证

Automatic signing

没有使用Automatic signing

结论

Xcode的Build Configuration和Code Signing Identity

Xcode的Run、Archive和Distribute App

iOS设备上打开App时的验证

重签名

原理

步骤

注意

结语

参考文章

相关文章

苹果NFC功能以及Apple Pay的初探

深入理解NFC

iOS 证书与签名解惑详解

iOS代码签名:Code Signing

iOS开发之超级签名-原理/机制/技术细节-完全解析(暂时还没有验证)

NXP的四款NFC芯片

iOS NFC

iOS Universal Link 简介