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是相同的。
了解了上面的概念，再来看开发及发布流程就非常简单了，而且相信你不用看教程也能一步步完成所有的操作了。
开发/真机调试流程
根据上面的介绍，可以知道进行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和证书进行签名，打包。
发布证书只跟自己的系统相关，与创建的应用（app id）无关的,
每种证书是独立的，当一个应用拥有多个证书时，我们创建provisioning file时使得这个应用拥有这些证书功能,
Provisioning Profiles 将appID,开发者证书，硬件Device绑定到一块的,
推送证书是和bundle ID绑定的，你要想推送证书也通用的话可以使用通配符* 的ID，这样可以在多个应用上使用，
及时删除过期的证书，登录apple网站重新导出push certificate，生成对应的p12，用p12生成对应的pem文
件，上传到对应的第三方推送，并上传pem到服务器即可。
