企业签名：苹果的 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 对应等。苹果企业签名找我们广州浅蓝谷科技。