證書管理

證書和P12文件創建

真機調試CER證書驗證
查看原圖

剛接觸iOS開發的人難免會對蘋果的各種證書、配置文件等不甚瞭解,可能你按照網上的教程一步一步的成功申請了真機調試,但是還是對其中的緣由一知半解。這篇文章就對Certificate、Provisioning Profile等做個總結。

 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

有一些類型的證書我沒有使用過,所以也不瞭解具體的作用。

Certificate.P12文件

當CER安裝到本地並與本機的私鑰吻合之後。我們一般會給證書做個備份,這個備份就是個P12文件。 這個p12文件很好用,它不僅包含CER的信息,還有私鑰信息,即: P12備份文件 = CER文件 + 私鑰;所以有了這個p12就再也不用擔心證書丟失了。

當合作開發需要共享證書時就可以把P12共享出去。比人拿到共享證書之後,在開發者網站上將欲調試的 iOS 設備註冊到該開發者賬號名下,並下載對應證書授權了 iOS 調試設備的 Provisioning Profile 文件,就可在 iOS 真機設備上開發調試了。

 

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 is the process of preparing and configuring an app to launch on devices and to use app services. During development, you choose which devices can run your app and which app services your app can access. A provisioning profile is downloaded from your developer account and embedded in the app bundle, and the entire bundle is code-signed. The embedded provisioning profile is installed on the device before the app is launched. If the information in the provisioning profile doesn’t match certain criteria, your app won’t launch. You indirectly configure a development provisioning profile by choosing options in Xcode.

翻譯:Provisioning是準備和配置app在設備上啓動並使用應用程序服務的過程.在開發過程中,您可以選擇哪些設備可以運行您的應用,以及您的應用可以啓用哪些服務。一個PP文件是通過開發者帳戶下載並嵌入到應用程序包,整個包是被私鑰簽名的。這個嵌入的PP文件在App啓動之前被安裝到設備上。如果PP文件的某些選項匹配不上,應用將不會啓動。

一個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證書相關的內容。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章