關於IOS的證書、App ID、設備、Provisioning Profile詳述

首先，打開developer.apple.com ，在iOS Dev Center打開Certificates, Indentifiers & Profiles認識一下基本結構。列表就包含了開發、調試和發佈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主要用來分發應用程序（根據證書種類有不一樣做用），下面是證書的分類信息：（括號內爲證書有效期）

• 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、In-House仍是Ad-Hoc，打包流程都是差很少的，都包括瞭如下幾個關鍵步驟：

• 建立發佈證書
• 建立App ID
• 建立對應的Provisioning Profile文件
• 設備Bundle ID和App ID一致
• 設置Xcode Code Sign Identifer，選擇合適的Profile和證書進行簽名，打包

推測iOS設備如何驗證app是否合法

關鍵的幾個點：

1. 解壓ipa

2. 取出embedded.mobileprovision，經過簽名校驗是否被篡改過

   1. 其中有幾個證書的公鑰，其中開發證書和發佈證書用於校驗簽名

   2. BundleId

   3. 受權列表

3. 校驗全部文件的簽名，包括Frameworks

4. 比對Info.plist裏面的BundleId是否符合embedded.mobileprovision文件中的