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文件，需要严格复杂的签名和验证流程

 

 

1. 创建.certSigningRequest文件，这时候会生成一对公私钥，这里称为公钥L（L：Local），私钥L。.certSigningRequest文件保存着公钥L

2. iOS 以及 mac OS上的AppleWWDRCA.cer 证书保存的就是苹果的公钥A（A：Apple），而对应的私钥A则在苹果的后台

3. 在苹果开发者网站上创建证书的时候，上传.certSigningRequest文件其实就是把公钥L传到苹果后台，用苹果后台里的私钥A去签名公钥L，得到对应的证书，把证书下载回来双击安装，会跟对应的私钥L绑定一起保存在keychain中

4. 除了证书，还需要对应的Provisioning Profile。在苹果开发者网站上：

   1. 设置App的Bundle ID
   2. 设置可安装该App的设备UDID
   3. 设置该App的权限
   4. 设置可以使用的证书
   5. 最后会使用私钥A把以上这些数据进行签名，组成一个Provisioning Profile，格式为.mobileprovision，下载回来双击安装，会保存在~/Library/MobileDevice/Provisioning Profiles中，文件名为它的UUID

5. 当需要把一个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文件

6. 把.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文件来源是权威的，最后只需要在用户设备上进行简单的验证就可以

 

 

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

更多相关

以上就是Code Signing最核心的内容，但在iOS开发中其实还有很多相关的概念，很多需要注意的地方，接下来会讲解一下我个人的观察和分析

苹果开发者帐号体系

Apple Developer：直接在Apple Developer登录，同意Apple Developer协议后的账号，免费，只可以使用Xcode进行真机调试，Xcode 7之后苹果推出的功能

Apple Developer Program：分个人和组织类型，费用都是每年 99 美元，可以使用Xcode进行真机调试，打包Ad-Hoc测试，在App Store发布App

Apple Developer Enterprise Program：企业账号，费用是每年 299 美元，可以使用Xcode进行真机调试，打包Ad-Hoc测试，打包In-House App，但不能在App Store发布App

不同安装方式对应的证书类型

• 非App Store
  • Development（真机调试）：iOS App Development
  • Ad Hoc：iOS Distribution (App Store and Ad Hoc)
  • Enterprise：iOS Distribution (In-House and Ad Hoc)
• App Store：iOS Distribution (App Store and Ad Hoc)

在iOS的项目中，只要不是运行在模拟器上，都会涉及到开发者帐号、证书、Provisioning Profile这些概念。

免费账号的限制：

• 创建的Provisioning Profile有效期只有7天
• 在7天内最多注册10个Bundle Id
• 只能同时注册3台iOS设备
• 在同一台iOS设备上，只能同时安装3个使用免费账号签名的App。当该设备上已经存在3个App，则无法安装任何免费账号签名的任何App，就算是那3个App其中一个也不行，只能先把其中一个删除

Automatic signing

在Xcode 7之前，只有加入到Apple Developer Program（即付费）才能进行真机调试，Xcode 7之后苹果推出了Automatic signing功能，只要在Xcode上登陆Apple ID，就会自动管理证书和Provisioning Profile，同时没有加入Apple Developer Program的账号也能进行真机调试。

 

 

在使用Xcode的Automatic signing功能的时候，无论是什么类型的账号，无论是直接Run进行真机调试，还是Archive，Code Signing Identity只能选用iOS Developer，只会使用iOS App Development类型的证书签名

如果不使用Automatic signing功能，则可以选择使用的是iOS App Development或者iOS Distribution证书进行签名

勾选Xcode中的AutoMatically manager signing，选择对应的Team后，无论是加入Apple Developer Program的账号（即付费账号）还是Apple Developer的账号（即免费账号）：

• 如果Xcode没有帮该账号自动生成过iOS App Development类型的证书， 无论在苹果后台是否已经存在其他iOS App Development类型的证书，都会生成一张新的iOS App Development类型证书，证书名称的格式是：开发者账号名称(当前Mac电脑名称)， 如：Brian Hui (Daniels的MacBook Pro)，同时会保存在当前Mac电脑的keychain中
• 免费账号无法进入苹果的管理证书后台，但可以猜测出在苹果后台也会存在该证书
• 如果Xcode没有帮该App的Bundle ID自动生成过对应的Provisioning Profile，就会使用上面那张证书生成一个Provisioning Profile，保存在~/Library/MobileDevice/Provisioning Profiles，但在苹果后台则不会存在这个Provisioning Profile
• 如果在钥匙串访问中删除了那张证书，Xcode会提示你的账号有iOS App Development类型的证书，但这台电脑没有安装，需要先把那张证书Revoke，Revoke后会再次重复前面的步骤，生成新的证书和Provisioning Profile
• 如果在~/Library/MobileDevice/Provisioning Profiles里面，删除了该Provisioning Profile文件，Xcode会马上重新生成Provisioning Profile

在使用Xcode的Automatic signing功能的前提下，进行Archive，然后Distribute App的时候，选择非Development的选项，再选择AutoMatically manager signing

• 如果本地存在iOS Distribution类型的证书，则会直接进行重签名

• 如果没有存在iOS Distribution类型的证书，而苹果的后台有，则会告诉你，该账号存在iOS Distribution类型的证书，但这台电脑没有安装，请联系创建人拿到备份（.p12文件）进行安装，当你安装了该证书（或者.p12文件），则会直接进行重签名

• 如果没有存在iOS Distribution类型的证书，而苹果的后台也没有，则Xcode会询问你是否需要生成iOS Distribution类型的证书，如果选择需要，则会自动生成iOS Distribution类型的证书，并且建议你保存在本地，证书名称的格式是：Team Name， 如：Hutchison Telephone (Macau) Company Limited，同时使用这张证书生成一个Provisioning Profile，保存在~/Library/MobileDevice/Provisioning Profiles，但在苹果后台则不会存在这个Provisioning Profile

Xcode对Provisioning Profile的验证

Xcode怎么把App和证书、Provisioning Profile绑定在一起呢？什么时候需要一张新的证书，什么时候需要一个新的Provisioning Profile？

Bundle ID是App的唯一标识，App和证书、Provisioning Profile绑定在一起，其实就是Bundle ID和证书、Provisioning Profile绑定在一起，两种情况：

Automatic signing

Bundle ID与开发者账号绑定。使用Automatic signing时，选择开发者账号（Team）后，Xcode会根据开发者账号去本地检索是否存在该账号对应的Provisioning Profile，再验证是否存在与该Bundle ID匹配的Provisioning Profile，再根据Provisioning Profile去本地检索是否存在对应的证书，都验证通过，则会设置成功。如果不存在Provisioning Profile，则会判断该Bundle ID是否已经被其他账号注册，如果已经被其他账号注册，则整个流程失败，需要选择对应的账号。如果该Bundle ID没有被其他账号注册或者账号已经对应上，则按照文章前面所说的步骤，最后生成Provisioning Profile。

没有使用Automatic signing

需要手动选择Provisioning Profile，当选择了其中一个Provisioning Profile时，则会分别验证Bundle ID是否对应、Provisioning Profile是否过期、是否存在对应的证书、App的权限是否对应、证书的类型和Code Signing Identity设置是否对应，如果都通过验证，则会设置成功。

结论

当你使用一台新的Mac电脑，进行开发、调试、发布某个开发者账号注册的App时，就需要一张新的证书（或者.p12文件）；当你使用新的证书或者新的App，就需要一张新的Provisioning Profile。一张证书对应一台Mac电脑，和一个开发者账号里面所有App，而一个Provisioning Profile则是只能对应一个App。

检验Provisioning Profile是签名的第一步，那如果Provisioning Profile通过检验，而Provisioning Profile里面又存在证书，为什么还需要单独安装证书呢？

答案是：Provisioning Profile里面证书的作用是验证本地是否有符合条件证书，并且在安装App的时候使用其中一张证书里面的公钥L来验证App的完整性和合法性。因为Provisioning Profile里面是有多张证书的，所以无法确定用哪张证书对应的私钥L用来签名，所以这些证书只能用于判断Mac电脑里有没有符合条件的证书，如果Mac电脑里有多张符合条件的证书，则默认用其中最新的证书里面的私钥L进行签名，这样就可以限制了只有获得符合条件的证书的Mac电脑，才能进行签名。

Mac电脑中证书的作用：1. 证明这台电脑是合法的；2. 找到对应的私钥L来对.app文件进行签名

Provisioning Profile中证书的作用：1. 判断这台电脑是否可以进行签名，也就是判断这个台电脑的合法性；2. 安装App时检验.app文件

Xcode的Build Configuration和Code Signing Identity

Xcode有Run、Archive、Test等几种项目构建方式，每一种可以指定不同的Build Configuration（默认有Debug和Release），而在Code Signing Identity又需要指定每种Build Configuration对应的配置，分别为iOS Developer和iOS Distribution，其实就是在设置Provisioning Profile的类型是开发的还是发布的

 

 

在使用Xcode的Automatic signing功能的时候，Code Signing Identity只能选择iOS Developer，否则会报错

Xcode的Run、Archive和Distribute App

Run和Archive的时候已经对App完成签名。如果设置的Provisioning Profile不是用于发布到App Store的，这时候把里面的.app文件打包成.ipa文件，可以利用Xcode或者其他工具直接安装到指定的iOS设备上。而点击Archives界面中Distribute App后，会再给你一次机会，选择其他证书和Provisioning Profile进行重签名，用于将App发布到不同的渠道

iOS设备上打开App时的验证

把App安装到iOS设备时，需要经过本文前面所说的验证，而打开App的时候，也需要验证：

• 使用付费账号生成的Development和AD-Hoc类型的.ipa文件，安装后打开对应的App时，不需要在iOS设备上进行信任开发者操作，每次打开都会验证证书和Provisioning Profile是否被Revoke或者过期，如果验证不通过，则无法打开

• 使用免费账号生成的Development和企业账号生成的Enterprise类型的.ipa文件，安装后第一次打开App时，需要在iOS设备上做额外的信任开发者操作，每次打开都会验证证书和Provisioning Profile是否被Revoke或者过期，如果验证不通过，则无法打开

• App Store下载的.ipa文件，安装后第一次打开App时，会验证当前登录的App ID是否已经购买该App，如果验证通过，则以后都可以正常打开，如果验证不通过则无法打开

重签名

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