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到服務器即可。
