iOS开发基础之开发证书的说明和发布

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文件的制作

该流程进行两次，分别创建开发测试用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等的介绍。

（转载原文链接：http://www.mamicode.com/info-detail-1126274.html）