企業簽名：蘋果的 App 簽名原理

首先，它既要有能不經蘋果私鑰驗證，立刻安裝的便利，又要通過蘋果驗證。

聽起來有點繞。蘋果採用的方案是雙層簽名。

在 Mac 生成一對公私鑰，這裏稱爲公鑰L，私鑰L。

蘋果本身有固定的一對公私鑰，私鑰在蘋果後臺，公鑰在每一個 iOS 設備上。

把公鑰 L 傳到蘋果後臺，用蘋果後臺裏的私鑰 A 去簽名公鑰 L。獲得一份數據包含了公鑰 L 以及其簽名，把這份數據稱爲證書。

在開發時，編譯完一個 APP 後，用本地的私鑰 L 對這個 APP 進行簽名，同時把第三步獲得的證書一塊兒打包進 APP 裏，安裝到手機上。

在安裝時，iOS 系統取得證書，經過系統內置的公鑰 A，去驗證證書的數字簽名是否正確。

驗證證書後確保了公鑰 L 是蘋果認證過的，再用公鑰 L 去驗證 APP 的簽名，這裏就間接驗證了這個 APP 安裝行爲是否通過蘋果官方容許。（這裏只驗證安裝行爲，不驗證APP 是否被改動，由於開發階段 APP 內容老是不斷變化的，蘋果不須要管。）

除了要保證通過驗證外，蘋果還要防止濫用這種途徑下載。

想象一下，把真機連到 Mac 上，不就能想裝多少裝多少 App 嗎？那多部設備連到 Mac 上，App 不就能想裝在哪裝在哪嗎？

蘋果的方案是識別 設備和 App。

想調試的設備必需要到開發者網站申請，而且設備數量是有限制的。

而後還針對每一個Bundle Identifier(App ID)配不一樣的證書。

這兩種數據都在上面第三步一塊兒組成證書（暫且這麼認爲）。

至此，證書就能實現 通過蘋果認證，而且能限制安裝設備數量和 App ID。

固然，證書不止有這些信息，還有推送等權限，蘋果把這些權限開關統一稱爲Entitlements。若是App 一開始的證書沒申請推送權限，那麼後面新增權限後，須要更新配置。

實際上，一個「證書」有規定的格式規範，不該把這些額外的信息往裏塞。因此上面的暫且這麼認爲部分是不對的。（若是沒有企業帳號可藉助第三方平臺（如：fywl689.com）得到蘋果企業簽名服務，這也是一個不錯的辦法。）

因此蘋果把證書和額外信息包裝起來，把它叫作Provisioning Profile。

因此能拓展整個流程圖以下。

在你的 Mac 開發機器生成一對公私鑰，這裏稱爲公鑰L，私鑰L。L:Local

蘋果本身有固定的一對公私鑰，跟上面 AppStore 例子同樣，私鑰在蘋果後臺，公鑰在每一個 iOS 設備上。這裏稱爲公鑰A，私鑰A。A:Apple

把公鑰 L 傳到蘋果後臺，用蘋果後臺裏的私鑰 A 去簽名公鑰 L。獲得一份數據包含了公鑰 L 以及其簽名，把這份數據稱爲證書。

在蘋果後臺申請 AppID，配置好設備 ID 列表和 APP 可以使用的權限，再加上第③步的證書，組成的數據用私鑰 A 簽名，把數據和簽名一塊兒組成一個 Provisioning Profile 文件，下載到本地 Mac 開發機。

在開發時，編譯完一個 APP 後，用本地的私鑰 L 對這個 APP 進行簽名，同時把第④步獲得的 Provisioning Profile 文件打包進 APP 裏，文件名爲 embedded.mobileprovision，把 APP 安裝到手機上。

在安裝時，iOS 系統取得證書，經過系統內置的公鑰 A，去驗證 embedded.mobileprovision 的數字簽名是否正確，裏面的證書籤名也會再驗一遍。

確保了 embedded.mobileprovision 裏的數據都是蘋果受權之後，就能夠取出裏面的數據，作各類驗證，包括用公鑰 L 驗證APP簽名，驗證設備 ID 是否在 ID 列表上，AppID 是否對應得上，權限開關是否跟 APP 裏的 Entitlements 對應等。