一篇介绍ios证书的博客

http://blog.sina.com.cn/s/blog_8d1bc23f0102vtzo.html

1.首先通过钥匙串访问——证书助理——从证书颁发机构请求证书——填写证书信息（邮箱，常用名称，存储到磁盘）——存储为（自定义名称.certSigningReuqest，简称CSR文件，只是为了提交到苹果开发者账号中，然后就没用了）到本地

2.苹果开发者账号中，创建证书（Development和Production）——上传CSR文件——下载证书运行 （ xxx.cer文件）

注意：只有在当前电脑中生成本地生成证书，上传到苹果开发账号，然后下载cer文件运行后，钥匙串中才有证书以及对应的秘钥











如果开发者B，登录开发者账号，下载证书（cer文件）运行，只有证书没有秘钥，是不能正常使用的



所以如果有新同事加入到开发组的时候，应该从本地钥匙串中选择证书，导出p12文件（包含证书和秘钥）给同事。另外可以给同事一份Provisioning Profiles文件（配置文件），用于本地开发识别测试设备

导出p12文件：钥匙串——选择证书——右键导出——存储为——设置p12文件密码

(发给同事后，双击p12文件，输入密码，本地安装证书成功)

需要强调一点，证书和项目关系其实并不大，证书一般有效期只有一年，当证书过期后，只需要重新生成一份证书，上传到开发者账号就行，同时因为原有证书过期，需要重新生成Provisioning Profiles文件。然后给同事们最新的p12文件和Provisioning Profiles文件就行

所以开发者账号中的证书，配置文件是可以放心操作的（比如误删了，或者找不到证书秘钥了）

Xcode中添加苹果开发者账号

Xcode工具栏——Xcode——Preferences——Accounts—— 左下角 Add Apple ID——输入苹果账号，密码

在项目的target——general——team中可以选择项目对应的开发者账号



（当bulid的新设备未在开发者账号的devices添加devicetoken的时候，xcode会进行提示无法识别设备，可以在xcode中fix issue，xcode会自动在开发者账号中，创建一个新的针对这个设备的Provisioning Profiles配置文件，然后安装到本地，唯一的不好就是开发者账号的配置文件下会有很多零散的配置文件）

关于App的发布

修改项目的version，以及项目的版本debug为release

（debug改为release后需要进行测试，一些第三方类库可能release版会有一些不兼容）

Product——Scheme——Edit Scheme 修改 Run/Test/Analyze/Archive 的build configuration  （发布的时候，只需要Archive就可以了）



苹果开发者中心——iTunes Connect——我的APP——创建/选择应用——填写基本修改/添加新版本（构建版本）

发布验证

Product——Desination——选择iOS Device

Product——Archive——右侧点击Validate——选择证书——validate——等待——Validate Successful——右侧点击Submit to App Store（提交构建版本）——Submission Successful







苹果开发者中心——iTunes Connect——我的APP——选择应用——提交构建版本成功——选择自动发布/手动发布——提交审核

等待审核

本文永久地址：http://blog.it985.com/11387.html

首先得描述一下各个证书的定位，作用，这样在制作的时候心中有谱，对整个流程的把握也会准确一些；

1、开发者证书（分为开发和发布两种，类型为ios Development,ios Distribution），这个是最基础的，不论是真机调试，还是上传到appstore都是需要的，是一个基证书，用来证明自己开发者身份的；

2、appID,这是每一个应用的独立标识，在设置项中可以配置该应用的权限，比如是否用到了PassBook,GameCenter,以及更常见的push服务，如果选中了push服务，那么就可以创建生成下面第3条所提到的推送证书，所以，在所有和推送相关的配置中，首先要做的就是先开通支持推送服务的appID;

3、推送证书（分为开发和发布两种，类型分别为APNs Development ios,APNs Distribution ios）,该证书在appID配置中创建生成，和开发者证书一样，安装到开发电脑上；

4、Provisioning Profiles,这个东西是很有苹果特色的一个东西，我一般称之为PP文件，该文件将appID,开发者证书，硬件Device绑定到一块儿，在开发者中心配置好后可以添加到Xcode上，也可以直接在Xcode上连接开发者中心生成，真机调试时需要在PP文件中添加真机的udid；是真机调试和上架必备之珍品；

平常我们的制作流程一般都是按以上序列进行，先利用开发者帐号登陆开发者中心，创建开发者证书，appID,在appID中开通推送服务，在开通推送服务的选项下面创建推送证书（服务器端的推送证书见下文），之后在PP文件中绑定所有的证书id,添加调试真机等；

具体操作流程如下：

1、开发者证书的制作，首先登陆到开发者中心，找到证书配置的版块，猛戳进入，点进证书，会显示如下界面，点击右上角的加号


会出现以下界面，该操作重复两次，分别创建开发测试证书和发布证书，开发测试证书用于真机调试，发布证书用于提交到appStore,我们以开发测试证书为例，选择第一个红框中的内容；


然后下一步，会提示创建CSR文件，也就是证书签名请求文件，会有很详细的操作说明，如果英文不太好，可以参考下图；





之后将该CSR文件保存到一处；

备注：CSR文件尽量每个证书都制作一次，将常用名称区分开来，因为该常用名称是证书中的密钥的名字；

之后在开发者中心将该CSR文件提交；


提交上去后就会生成一个cer证书，如图所示，有效期为一年；



利用同样的方法配置一下Distribution发布证书，下载保存，双击安装；在钥题串登陆证书中可以查看，其中专用密钥的名字即为CSR请求文件中的常用名称；

2、以上开发者证书的配置完成了，下面我们来配置appID和推送证书；在左边栏中选择appID,勾选右边的push可选项，为该appID所对应的应用添加推送功能，下面会看到创建证书的按钮，分别为开发证书和发布证书，下面的流程就和上述1中创建证书一样了，都是先建立证书请求文件，然后提交生成就行了，需要注意的是，虽然在左边栏证书栏中也可以直接创建推送证书，但是还是建议在appID中，勾选了push服务后在此处创建，这样会避免因为忘了开通push服务而导致推送不可用的情况发生；



证书创建完成后，下载保存，双击安装即可；

3、最后我们来进行PP
20a3a
文件的制作



该流程进行两次，分别创建开发测试用PP文件和发布PP文件，前者用于真机测试，后者用于提交发布；Ad Hoc格式一般用于企业帐号，此处我们忽略；

选择后提交


会自动检测匹配appID,另外下拉项中还可以选择wildCard格式，该格式为自动生成，使用*通配符，适用于批量的，没有推送，PassCard等服务的应用；我们选择我们刚刚创建的appID,之后下一步选择证书；



继续，这里有一个区别，因为PP文件的开发测试版需要真机调试，所以我们需要绑定真机，这里因为之前我添加过一些设备，所以这里就可以直接全选添加，如果没有的话，需要将真机的udid复制出来在此添加，在发布PP文件中，是没有这一步的；



之后就是输入一个PP文件的名字了，然后生成，下载保存，双击添加到Xcode库中，这样在真机调试或者发布时，就可以分别有不同的PP文件与其对应；



添加到Xcode中的效果如下：



到目前为止，客户端开发和上架所需要的证书文件配置都已经配齐了，天色已晚，明天再配置服务端所用到的推送证书吧，到时候另起一章，将ios诡异的推送流程也捋一捋，本来想写到一篇里的，没想到整了这么长，下班回家开黑去喽！

本文永久地址：http://blog.it985.com/11383.html

 1.概念介绍

如果你拥有一个开发者账户的话，在iOS Dev Center打开Certificates, Indentifiers & Profiles，你就可以看到如下的列表：



Profile Portal改版有一段时间了，改版之后的结构比以前更清晰明了，易于理解和管理。

上面的列表就包含了开发、调试和发布iOS应用程序所需的所有内容：Certificates、Identifiers、Devices、Provisioning Profiles。下面将一一解释这几个东东。

 

Certificate

证书是用来给应用程序签名的，只有经过签名的应用程序才能保证他的来源是可信任的，并且代码是完整的， 未经修改的。在Xcode Build Setting的Code Signing Identity中，你可以设置用于为代码签名的证书。

众所周知，我们申请一个Certificate之前，需要先申请一个Certificate Signing Request (CSR) 文件，而这个过程中实际上是生成了一对公钥和私钥，保存在你Mac的Keychain中。代码签名正是使用这种基于非对称秘钥的加密方式，用私钥进行签名，用公钥进行验证。如下图所示，在你Mac的keychain的login中存储着相关的公钥和私钥，而证书中包含了公钥。你只能用私钥来进行签名，所以如果没有了私钥，就意味着你不能进行签名了，所以就无法使用这个证书了，此时你只能revoke之前的证书再申请一个。因此在申请完证书时，最好导出并保存好你的私钥。当你想与其他人或其他设备共享证书时，把私钥传给它就可以了。私钥保存在你的Mac中，而苹果生成的Certificate中包含了公钥。当你用自己的私钥对代码签名后，苹果就可以用证书中的公钥来进行验证，确保是你对代码进行了签名，而不是别人冒充你，同时也确保代码的完整性等。



证书主要分为两类：Development和Production，Development证书用来开发和调试应用程序，Production主要用来分发应用程序（根据证书种类有不同作用），下面是证书的分类信息：（括号内为证书有效期）

（注：不同类型的开发者账户所能创建的证书种类不同，关于开发者账户的对比和InHouse证书相关的内容，请见我的另一篇文章）

Development

App Development (1年)：用来开发和真机调试应用程序。

Push Development (1年)：用来调试Apple Push Notification

Production

In-House and Ad Hoc (3年)：用来发布In-House和AdHoc的应用程序。

 
App Store ：用来发布提交App Store的应用程序。

MDM CSR

Push Production (1年)：用来在发布版本中使用Apple Push Notification。

Pass Type ID Certificate

Website Push ID Certificate

有一些类型的证书我没有使用过，所以也不了解具体的作用。

 

App ID

App ID用于标识一个或者一组App，App ID应该是和Xcode中的Bundle ID是一致的或者匹配的。App ID主要有以下两种： 

Explicit App ID：唯一的App ID，这种App ID用于唯一标识一个应用程序，例如com.ABC.demo1，标识Bundle ID为com.ABC.demo1的程序。

Wildcard App ID：通配符App ID，用于标识一组应用程序。例如*可以表示所有应用程序，而com.ABC.*可以表示以com.ABC开头的所有应用程序。

每创建一个App ID，我们都可以设置该App ID所使用的APP Services，也就是其所使用的额外服务。每种额外服务都有着不同的要求，例如，如果要使用Apple Push Notification Services，则必须是一个explicit App ID，以便能唯一标识一个应用程序。下面是目前所有可选的服务和相应的配置要求。



如果你的App使用上述的任何一种service，就要按照要求去配置。

 

Device

Device最简单了，就是iOS设备。Devices中包含了该账户中所有可用于开发和测试的设备。 每台设备使用UDID来唯一标识。

每个账户中的设备数量限制是100个。Disable 一台设备也不会增加名额，只能在membership year 开始的时候才能通过删除设备来增加名额。

关于设备数量的问题，详见这篇文章。

 

Provisioning Profile

一个Provisioning Profile文件包含了上述的所有内容：证书、App ID、设备。

试想一下，如果我们要打包或者在真机上运行一个应用程序，我们首先需要证书来进行签名，用来标识这个应用程序是合法的、安全的、完整的等等；然后需要指明它的App ID，并且验证Bundle ID是否与其一致；再次，如果是真机调试，需要确认这台设备能否用来运行程序。而Provisioning Profile就把这些信息全部打包在一起，方便我们在调试和发布程序打包时使用，这样我们只要在不同的情况下选择不同的profile文件就可以了。而且这个Provisioning Profile文件会在打包时嵌入.ipa的包里。

例如，如下图所示，一个用于Development的Provisioning Profile中包含了该Provisioning Profile对应的App ID，可使用的证书和设备。这意味着使用这个Provisioning Profile打包程序必须拥有相应的证书，并且是将App ID对应的程序运行到Devices中包含的设备上去。



如上所述，在一台设备上运行应用程序的过程如下：



与证书一样，Provisioning Profile也分为Development和Distribution两种：

（注：前面提到不同账户类型所能创建的证书种类不同，显然Profile文件的种类是和你所能创建的证书种类相关的）

Development (1年)

Distribution (1年)

In House

Ad Hoc

App Store

In House 与Ad Hoc的不同之处在于：In House没有设备数量限制，而Ad Hoc是用来测试用的，Ad Hoc的包只能运行在该账户内已登记的可用设备上，显然是有最多100个设备的数量限制。所以这两种Provisioning Profile文件的区别就在于其中的设备限制不一样而已，而他们所使用的Certificate是相同的。

2.开发/发布流程

了解了上面的概念，再来看开发及发布流程就非常简单了，而且相信你不用看教程也能一步步完成所有的操作了。

开发/真机调试流程

根据上面的介绍，可以知道进行Development主要有以下几个步骤：

申请证书

加入设备

生成Provisioning Profile

设置Xcode Code Sign Identifer

事实上第三步通常是不需要的，因为我们通常都是用Xcode生成和管理的iOS Team Provisioning Profile来进行开发，因为它非常方便，所以不需要自己手动生成Provisioning Profile。

iOS Team Provisioning Profile是第一次使用Xcode添加设备时，Xcode自动生成的，它包含了Xcode生成的一个Wildcard App ID（*，匹配所有应用程序），账户里面所有的Devices和所有Development Certificates，如下图所示。因此，team中的所有成员都可以使用这个iOS Team Provisioning Profile在team中的所有设备上调试所有的应用程序。并且当有新设备添加进来时，Xcode会更新这个文件。



发布流程

网上有很多关于发布App Store的流程，我就不缀述了，不过根据上面的概念介绍，不管是App Store、In-House还是Ad-Hoc，打包流程都是差不多的，都包括了以下几个关键步骤：

创建发布证书

创建App ID

创建对应的Provisioning Profile文件

设备Bundle ID和App ID一致

设置Xcode Code Sign Identifer，选择合适的Profile和证书进行签名，打包

以上就是对证书、Provisioning Profile、App ID等的介绍，下一篇文章会介绍以下In-House证书相关的内容。

本文永久地址：http://blog.it985.com/11375.html
http://blog.csdn.net/TuGeLe/article/details/78868236

前言

在移动开发中，iOS系统下的app和andorid系统下的app一个很大的区别是：android系统下，app的安装很方便，可以从多个应用商店下载（小米应用商店、华为应用商店），也可以直接下载apk的包安装。而在iOS系统下，对app的安装限制比较严格，非开发的app，只能从App Store下载。即使是开发人员，拥有开发者帐号，所开发的app 也不能随意的安装，有最多100台设备的限制，还需要知道设备的UDID……苹果这样做的目的是保证每个app都是经过检验的，都是经过苹果官方审核允许的。那么苹果是如何做到这一点的呢？这就和本文要介绍的内容相关，iOS
app的签名机制。 

在介绍iOS app签名机制之前，先介绍一些关于加密的知识。

常用的加密方式

目前主流的加密方式有对称密钥加密和非对称密钥加密。

对称密钥加密

维基百科中对对称密钥加密的定义如下：

对称密钥加密（英语：Symmetric-key algorithm）又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密算法。这类算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥

简单来说，就是加密方和解密方使用的是同一个密钥。 

常见的对称密钥加密有AES、DES 等。

非对称密钥加密

非对称密钥加密，又称为公开密钥加密。 

非对称密钥加密需要两个密钥，一个是公开密钥，一个是私有密钥。私有密钥用来加密，公开密钥用来解密。私有密钥由加密方保管，公有密钥则公布出来。 

实际上，私有密钥和共有密钥在数学上是有一定的关系的。但是仅仅从共有密钥是推断不出私有密钥的，这也是共有密钥可以公布出来的原因。 

通过共有密钥推断私有密钥和质数分解有关。目前质数分解没有特别快的算法，通常是通过暴力枚举的方法来分解。当质数非常大时（如2的1024次方级别），暴力分解质数是不现实的，因此非对称加密是安全的。 

非对称加密的安全还依赖于加密方对私钥的管理，一旦私钥暴露，也就毫无加密可言。 

常见的非对称加密有RSA、DSA。

MD5加密

MD5全称MD5消息摘要算法（MD5 Message-Digest Algorithm）。严格来说，MD5并不是一种加密方式，MD5只是一个哈希算法，对同一个明文生成的密文（哈希值）是统一的。MD5相较于普通加密来说还有一个优点：MD5生成的密文长度很短（16位或者32位字符）。

数字签名

了解了常用加密方式之后，介绍一下数字签名，数字签名实际上和生活中的签名效果一致。想一下工作中的报销，报销单只有经过领导签名之后，递交给财务，财务才会发对应的钱。这里的领导签名实际是保证了两件事： 

1. 这笔钱的花销是合理的，应该报销 

2. 这笔钱的数目是正确的 

即：数据是正确的，且是领导认可的。 

现实生活中这样做当然是没有问题的，然而在网络上呢，比如客户端请求服务器的数据，如何确认数据中间没有被篡改过？肯定不能像现实中使用笔来签名，于是就有了数字签名。 

数字签名和现实生活中签名的作用是一致的，即： 

1. 保证数据没有没有被篡改过 

2. 保证数据是经过我认证的 

数字签名是如何保证上述两点的呢？使用的是非对称加密+MD5线性加密。 

数字签名的过程如下： 



1. 首先算出原始数据的摘要。这里的算法要保证：如果原始数据有任何变化，则摘要也会发生变化；对同一份原始数据，使用相同的算法，计算出的摘要是相同的。这一步使用的算法通常是MD5消息摘要算法。 

2. 生成一对公钥和私钥，使用非对称加密方式，用私钥对上一步生成的摘要进行加密，加密的结果就是数字签名。 

3. 在返回数据时，将原始数据和数字签名一起返回给请求数据方。 

请求数据方在接收到数据之后，如何确认数据正确以及数据是合法的呢？请求数据方含有公钥，会对数字签名进行验证，过程如下： 



1. 首先用含有的公钥对数字签名进行解密，如果能够解密成功，说明返回的数据是经过数据发送方认证的（否则数据发送方不会对该数据加密）。 

2. 对原始的数据使用MD5算法，生成原始数据的摘要。 

3. 对比第一步和第二步生成的摘要，如果生成的摘要相等，说明原始数据没有被篡改过。 

由此，通过数字签名可以达到确保数据没有被篡改过以及数据是合法的目的。

通过AppStore下载的app签名机制

了解了数字签名之后，来看下苹果是如何通过AppStore确保app合法的。 

我们都知道，iPhone只有一家生产商，iOS系统只有一个开发者，那就是苹果公司。因此苹果公司可以在所有的iOS系统中做一些统一的事情。实际上，苹果公司生成了一对私钥和公钥，每一个iOS 系统上都内置有公钥，而私钥保存在苹果后台上。开发者再将app上传到苹果服务器之后，苹果公司使用私钥对app进行数字签名。用户从AppStore 下载的app，既包含app包，也包含数字签名。下载到本地后，iOS 系统使用公钥验证签名，就可以确定该app 是经过苹果公司认证的，且包没有被篡改过。整个流程如下： 



如果app仅仅只能从AppStore下载安装，那无疑是非常简单的。实际上，除了从AppStore下载安装，开发者还可以通过Xcode打包来安装，打好的包还可以安装在100台设备上，那么这些是如何控制的呢？

通过Xcode将app安装到手机上

在申请成为苹果开发者之后，可以通过Xcode将开发的app安装到手机上，实际上，即使是开发时的app，也需要通过苹果的验证。对于开发时app的安装，苹果使用的是双层验证。先看一些其他的知识。

CertificateSigningRequest文件

申请成为苹果开发者之后，需要在开发者后台上传 CertificateSigningRequest文件，那么CertificateSigningRequest 到底是什么呢？ 

CertificateSigningRequest 实际上是本地Mac 生成的公钥文件。 

Mac可以通过钥匙串访问中的从证书颁发机构请求证书生成一对公钥、私钥。如下图： 



生成的CertificateSigningRequest文件里面保存的是公钥，私钥保存在本地Mac 中。

p12文件

在工作中，通常是多个同事共同开发一个app，每个人都可以安装app到真机上。多个人共同开发一个app时，就需要公用一份p12文件。那么p12文件又是什么呢？ 

p12其实就是保存在本地Mac的私钥。本地Mac的私钥可以导出，导出后的文件即为p12文件。如下图: 

双层签名机制

双层签名的流程如下： 



1. 在本地Mac 生成一对公钥、私钥 

2. 苹果生成一对公钥、私钥。其中私钥在苹果后台管理，每台iOS设备中都有公钥。 

3. 将本地Mac生成的公钥（CertificateSigningRequest）上传至开发者后台，在这个过程中，苹果会使用私钥对该公钥进行签名，最后生成一个证书文件。该证书文件中包含公钥L的原始数据，以及签名信息。开发者需要将该证书下载到本地的Mac。 

4. 在开发阶段，将app安装到手机上时，使用本地Mac的私钥（p12文件）对app进行签名，最终打包到手机上的有 App原数据，使用本地私钥对app加密后的签名文件，以及上一步下载的证书文件。 

5. iOS 设备使用公钥A验证证书中的签名，如果验证通过，说明该公钥是经过苹果认证的（也就是证实了开发者身份）。 

6. 之后使用证书中的公钥L 验证App 签名，如果验证通过，说明该app 的安装是合法的。 

这样，通过两次验证，间接验证了app的安装是经过苹果允许的。 

通过上述的双层验证，只是保证了某app的安装是经过苹果允许的，实际上苹果还有更多的限制： 

1. 只有属于开发者开发的app 才被允许安装 

2. 开发者开发的app不能被随便安装，最多只能安装到100台设备上。 

为了达到上述两个目的，上面流程中在使用私钥A对本地公钥加密时，还有一些其他的信息，如AppID，设备列表等。加上额外信息的流程如下： 



主要变化在第3步。使用私钥加密生成数字签名时，不仅仅是本地的公钥，还包括在开发者后台设置的AppID和设备列表。 

第5步验证时，如果签名验证通过，说明本地的公钥是经过苹果认证的，且设备列表和AppID 没有被篡改过。 

第6步验证时，除了验证App签名，还要验证该设备是否在设备列表中，AppID是否正确等信息。 

通过这些附加的信息，就限制了安装数量，避免被滥用。 

这也是为何当在开发者后台添加新的设备UDID 时，需要更新证书的原因。因为重新添加了UDID，苹果会重新用私钥加密，重新生成一个新的证书。 

到这一步，我们基本上理解了iOS app的签名机制。通过上面的介绍，可以看到第三步生成的证书是非常复杂的，包含了非常多的信息。实际上，除了上述的内容，还有一些推送等权限也需要控制，这些数据也需要签名验证。如果再加上这些信息，证书会变的非常复杂，而且证书也是有一些固定格式的，太多的内容也不符合证书的格式。为了解决这个问题，苹果又搞了个Provisioning Profile文件（也就是俗称的pp文件）。Provisioning Profile文件中除了包含证书，还包含设备列表、AppID、各种权限控制等。 

对于各种权限的控制，苹果也统一的处理了一下，叫做Entitlements 文件。 

最终的流程也就变成了下面这样： 



实际的开发环境中，在将本地的公钥传到开发者中心后，在开发者中心配置设备列表、AppID、以及各种权限控制，之后苹果使用自己的私钥对这些数据进行签名，生成Provisioning Profile文件。开发时，需要将Provisionging Profile文件下载到本地，通过Xcode打包时，会将Provisioning Profile 文件也一起打包进app中。 https://wereadteam.github.io/2017/03/13/Signature/

iOS App 签名的原理

发表于 2017-03-13   |   作者: bang   |  

iOS 签名机制挺复杂，各种证书，Provisioning Profile，entitlements，CertificateSigningRequest，p12，AppID，概念一堆，也很容易出错，本文尝试从原理出发，一步步推出为什么会有这么多概念，希望能有助于理解 iOS App 签名的原理和流程。

目的

先来看看苹果的签名机制是为了做什么。在 iOS 出来之前，在主流操作系统(Mac/Windows/Linux)上开发和运行软件是不需要签名的，软件随便从哪里下载都能运行，导致平台对第三方软件难以控制，盗版流行。苹果希望解决这样的问题，在 iOS 平台对第三方 APP 有绝对的控制权，一定要保证每一个安装到 iOS 上的 APP 都是经过苹果官方允许的，怎样保证呢？就是通过签名机制。

非对称加密

通常我们说的签名就是数字签名，它是基于非对称加密算法实现的。对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。
简单说一下常用的非对称加密算法 RSA 的数学原理，理解简单的数学原理，就可以理解非对称加密是怎么做到的，为什么会是安全的：
选两个质数 

p

 和 

q

，相乘得出一个大整数

n

，例如
p=61，q=53，n=pq=3233
选 1-n 间的随便一个质数 

e

，例如 e = 17
经过一系列数学公式，算出一个数字 

d

，满足：

a. 通过 

n

 和 

e

 这两个数据一组数据进行数学运算后，可以通过
n 和 d 去反解运算，反过来也可以。

b. 如果只知道 

n

 和 

e

，要推导出 

d

，需要知道 

p

 和 

q

，也就是要需要把
n 因数分解。
上述的 

(n,e)

 这两个数据在一起就是公钥，

(n,d)

 这两个数据就是私钥，满足用公钥加密，私钥解密，或反过来公钥加密，私钥解密，也满足在只暴露公钥（只知道 

n

 和
e）的情况下，要推导出私钥 

(n,d)

，需要把大整数 

n

 因数分解。目前因数分解只能靠暴力穷举，而n数字越大，越难以用穷举计算出因数 

p

 和 

q

，也就越安全，当 

n

 大到二进制
1024 位或 2048 位时，以目前技术要破解几乎不可能，所以非常安全。
若对数字 

d

 是怎样计算出来的感兴趣，可以详读这两篇文章：RSA
算法原理（一）（二）

数字签名

现在知道了有非对称加密这东西，那数字签名是怎么回事呢？
数字签名的作用是我对某一份数据打个标记，表示我认可了这份数据（签了个名），然后我发送给其他人，其他人可以知道这份数据是经过我认证的，数据没有被篡改过。
有了上述非对称加密算法，就可以实现这个需求：



首先用一种算法，算出原始数据的摘要。需满足 a.若原始数据有任何变化，计算出来的摘要值都会变化。 b.摘要要够短。这里最常用的算法是MD5。
生成一份非对称加密的公钥和私钥，私钥我自己拿着，公钥公布出去。
对一份数据，算出摘要后，用私钥加密这个摘要，得到一份加密后的数据，称为原始数据的签名。把它跟原始数据一起发送给用户。
用户收到数据和签名后，用公钥解密得到摘要。同时用户用同样的算法计算原始数据的摘要，对比这里计算出来的摘要和用公钥解密签名得到的摘要是否相等，若相等则表示这份数据中途没有被篡改过，因为如果篡改过，摘要会变化。
之所以要有第一步计算摘要，是因为非对称加密的原理限制可加密的内容不能太大（不能大于上述 n 的位数，也就是一般不能大于 1024 位/ 2048 位），于是若要对任意大的数据签名，就需要改成对它的特征值签名，效果是一样的。
好了，有了非对称加密的基础，知道了数字签名是什么，怎样可以保证一份数据是经过某个地方认证的，来看看怎样通过数字签名的机制保证每一个安装到 iOS 上的 APP 都是经过苹果认证允许的。

最简单的签名

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



如果我们 iOS 设备安装 APP 只有从 AppStore 下载这一种方式的话，这件事就结束了，没有任何复杂的东西，只有一个数字签名，非常简单地解决问题。
但实际上因为除了从 AppStore 下载，我们还可以有三种方式安装一个 App：
开发 App 时可以直接把开发中的应用安装进手机进行调试。
In-House 企业内部分发，可以直接安装企业证书签名后的 APP。
AD-Hoc 相当于企业分发的限制版，限制安装设备数量，较少用。
苹果要对用这三种方式安装的 App 进行控制，就有了新的需求，无法像上面这样简单了。

新的需求

我们先来看第一个，开发时安装APP，它有两个个需求：
安装包不需要传到苹果服务器，可以直接安装到手机上。如果你编译一个 APP 到手机前要先传到苹果服务器签名，这显然是不能接受的。
苹果必须对这里的安装有控制权，包括

a.经过苹果允许才可以这样安装。

b.不能被滥用导致非开发app也能被安装。
为了实现这些需求，iOS 签名的复杂度也就开始增加了。
苹果这里给出的方案是使用了双层签名，会比较绕，流程大概是这样的：



在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第三步得到的证书一起打包进 APP 里，安装到手机上。
在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证证书的数字签名是否正确。
验证证书后确保了公钥 L 是苹果认证过的，再用公钥 L 去验证 APP 的签名，这里就间接验证了这个 APP 安装行为是否经过苹果官方允许。（这里只验证安装行为，不验证APP 是否被改动，因为开发阶段 APP 内容总是不断变化的，苹果不需要管。）

加点东西

上述流程只解决了上面第一个需求，也就是需要经过苹果允许才可以安装，还未解决第二个避免被滥用的问题。怎么解决呢？苹果再加了两个限制，一是限制在苹果后台注册过的设备才可以安装，二是限制签名只能针对某一个具体的 APP。
怎么加的？在上述第三步，苹果用私钥 A 签名我们本地公钥 L 时，实际上除了签名公钥 L，还可以加上无限多数据，这些数据都可以保证是经过苹果官方认证的，不会有被篡改的可能。



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

最终流程

到这里这个证书已经变得很复杂了，有很多额外信息，实际上除了 设备 ID / AppID，还有其他信息也需要在这里用苹果签名，像这个 APP 里 iCloud / push / 后台运行 等权限苹果都想控制，苹果把这些权限开关统一称为 Entitlements，它也需要通过签名去授权。
实际上一个“证书”本来就有规定的格式规范，上面我们把各种额外信息塞入证书里是不合适的，于是苹果另外搞了个东西，叫 Provisioning Profile，一个 Provisioning Profile 里就包含了证书以及上述提到的所有额外信息，以及所有信息的签名。
所以整个流程稍微变一下，就变成这样了：



因为步骤有小变动，这里我们不辞啰嗦重新再列一遍整个流程：
在你的 Mac 开发机器生成一对公私钥，这里称为公钥L，私钥L。L:Local
苹果自己有固定的一对公私钥，跟上面 AppStore 例子一样，私钥在苹果后台，公钥在每个 iOS 设备上。这里称为公钥A，私钥A。A:Apple
把公钥 L 传到苹果后台，用苹果后台里的私钥 A 去签名公钥 L。得到一份数据包含了公钥 L 以及其签名，把这份数据称为证书。
在苹果后台申请 AppID，配置好设备 ID 列表和 APP 可使用的权限，再加上第③步的证书，组成的数据用私钥 A 签名，把数据和签名一起组成一个 Provisioning Profile 文件，下载到本地 Mac 开发机。
在开发时，编译完一个 APP 后，用本地的私钥 L 对这个 APP 进行签名，同时把第④步得到的 Provisioning Profile 文件打包进 APP 里，文件名为 

embedded.mobileprovision

，把
APP 安装到手机上。
在安装时，iOS 系统取得证书，通过系统内置的公钥 A，去验证 

embedded.mobileprovision

 的数字签名是否正确，里面的证书签名也会再验一遍。
确保了 

embedded.mobileprovision

 里的数据都是苹果授权以后，就可以取出里面的数据，做各种验证，包括用公钥 L 验证APP签名，验证设备
ID 是否在 ID 列表上，AppID 是否对应得上，权限开关是否跟 APP 里的 Entitlements 对应等。
开发者证书从签名到认证最终苹果采用的流程大致是这样，还有一些细节像证书有效期/证书类型等就不细说了。

概念和操作

上面的步骤对应到我们平常具体的操作和概念是这样的：
第 1 步对应的是 keychain 里的 “从证书颁发机构请求证书”，这里就本地生成了一堆公私钥，保存的 

CertificateSigningRequest

 就是公钥，私钥保存在本地电脑里。
第 2 步苹果处理，不用管。
第 3 步对应把 

CertificateSigningRequest

 传到苹果后台生成证书，并下载到本地。这时本地有两个证书，一个是第 1 步生成的，一个是这里下载回来的，keychain
会把这两个证书关联起来，因为他们公私钥是对应的，在XCode选择下载回来的证书时，实际上会找到 keychain 里对应的私钥去签名。这里私钥只有生成它的这台 Mac 有，如果别的 Mac 也要编译签名这个 App 怎么办？答案是把私钥导出给其他 Mac 用，在 keychain 里导出私钥，就会存成 

.p12

 文件，其他
Mac 打开后就导入了这个私钥。
第 4 步都是在苹果网站上操作，配置 AppID / 权限 / 设备等，最后下载 Provisioning Profile 文件。
第 5 步 XCode 会通过第 3 步下载回来的证书（存着公钥），在本地找到对应的私钥（第一步生成的），用本地私钥去签名 App，并把 Provisioning Profile 文件命名为 

embedded.mobileprovision

 一起打包进去。这里对
App 的签名数据保存分两部分，Mach-O 可执行文件会把签名直接写入这个文件里，其他资源文件则会保存在 

_CodeSignature

 目录下。
第 6 - 7 步的打包和验证都是 Xcode 和 iOS 系统自动做的事。
这里再总结一下这些概念：
证书：内容是公钥或私钥，由其他机构对其签名组成的数据包。
Entitlements：包含了 App 权限开关列表。
CertificateSigningRequest：本地公钥。
p12：本地私钥，可以导入到其他电脑。
Provisioning Profile：包含了 证书 / Entitlements 等数据，并由苹果后台私钥签名的数据包。

其他发布方式

前面以开发包为例子说了签名和验证的流程，另外两种方式 In-House 企业签名和 AD-Hoc 流程也是差不多的，只是企业签名不限制安装的设备数，另外需要用户在 iOS 系统设置上手动点击信任这个企业才能通过验证。
而 AppStore 的签名验证方式有些不一样，前面我们说到最简单的签名方式，苹果在后台直接用私钥签名 App 就可以了，实际上苹果确实是这样做的，如果去下载一个 AppStore 的安装包，会发现它里面是没有 

embedded.mobileprovision

 文件的，也就是它安装和启动的流程是不依赖这个文件，验证流程也就跟上述几种类型不一样了。
据猜测，因为上传到 AppStore 的包苹果会重新对内容加密，原来的本地私钥签名就没有用了，需要重新签名，从 AppStore 下载的包苹果也并不打算控制它的有效期，不需要内置一个 

embedded.mobileprovision

 去做校验，直接在苹果用后台的私钥重新签名，iOS
安装时用本地公钥验证 App 签名就可以了。
那为什么发布 AppStore 的包还是要跟开发版一样搞各种证书和 Provisioning Profile？猜测因为苹果想做统一管理，Provisioning Profile 里包含一些权限控制，AppID 的检验等，苹果不想在上传 AppStore 包时重新用另一种协议做一遍这些验证，就不如统一把这部分放在 Provisioning Profile 里，上传 AppStore 时只要用同样的流程验证这个 Provisioning
Profile 是否合法就可以了。
所以 App 上传到 AppStore 后，就跟你的 证书 / Provisioning Profile 都没有关系了，无论他们是否过期或被废除，都不会影响 AppStore 上的安装包。
到这里 iOS 签名机制的原理和主流程大致说完了，希望能对理解苹果签名和排查日常签名问题有所帮助。

P.S.一些疑问

最后这里再提一下我关于签名流程的一些的疑问。

企业证书

企业证书签名因为限制少，在国内被广泛用于测试和盗版，fir.im / 蒲公英等测试平台都是通过企业证书分发，国内一些市场像 PP 助手，爱思助手，一部分安装手段也是通过企业证书重签名。通过企业证书签名安装的 App，启动时都会验证证书的有效期，并且不定期请求苹果服务器看证书是否被吊销，若已过期或被吊销，就会无法启动 App。对于这种助手的盗版安装手段，苹果想打击只能一个个吊销企业证书，并没有太好的办法。
这里我的疑问是，苹果做了那么多签名和验证机制去限制在 iOS 安装 App，为什么又要出这样一个限制很少的方式让盗版钻空子呢？若真的是企业用途不适合上 AppStore，也完全可以在 AppStore 开辟一个小的私密版块，还是通过 AppStore 去安装，就不会有这个问题了。

AppStore
加密

另一个问题是我们把 App 传上 AppStore 后，苹果会对 App 进行加密，导致 App 体积增大不少，这个加密实际上是没卵用的，只是让破解的人要多做一个步骤，运行 App 去内存 dump 出可执行文件而已，无论怎样加密，都可以用这种方式拿出加密前的可执行文件。所以为什么要做这样的加密呢？想不到有什么好处。

本地私钥

我们看到前面说的签名流程很绕很复杂，经常出现各种问题，像有 Provisioning Profile 文件但证书又不对，本地有公钥证书没对应私钥等情况，不理解原理的情况下会被绕晕，我的疑问是，这里为什么不能简化呢？还是以开发证书为例，为什么一定要用本地 Mac 生成的私钥去签名？苹果要的只是本地签名，私钥不一定是要本地生成的，苹果也可以自己生成一对公私钥给我们，放在 Provisioning Profile 里，我们用里面的私钥去加密就行了，这样就不会有 

CertificateSigningRequest

 和 

p12

 的概念，跟本地
keychain 没有关系，不需要关心证书，只要有 Provisioning Profile 就能签名，流程会减少，易用性会提高很多，同时苹果想要的控制一点都不会少，也没有什么安全问题，为什么不这样设计呢？
能想到的一个原因是 Provisioning Profile 在非 AppStore 安装时会打包进安装包，第三方拿到这个 Provisioning Profile 文件就能直接用起来给他自己的 App 签名了。但这种问题也挺好解决，只需要打包时去掉文件里的私钥就行了，所以仍不明白为什么这样设计。