导读：iOS签名校验机制是苹果生态安全的核心，贯穿于开发、测试与发布全过程。本文系统解析数字签名与证书原理，梳理开发者证书生成流程，并深入剖析苹果签名校验机制的关键环节与核心组件，帮助开发者高效应对签名相关问题。
全文约9500字，预计阅读时间24分钟。
背景
iOS 15 beta发布后，企业级IPA包在新系统上无法安装，提示“The code signature version is no longer supported”。通过控制台日志及codesign命令分析发现，问题源于代码签名格式过旧——CodeDirectory版本为v=20400，已被iOS 15强制淘汰。
根据苹果官方文档，macOS 10.14及以上系统默认使用新签名格式。若CodeDirectory版本低于20400，需重新签名。实测在macOS 11.5.2和macOS 12.0 Beta环境下对原IPA重签名后，可成功安装至iOS 15设备。
此案例体现了iOS签名校验机制的严格性。类似问题还包括因系统时间异常导致证书失效、企业包启动崩溃等。下文将系统梳理iOS证书与签名校验机制，助力开发者深入理解并有效应对。
核心问题解析
什么是签名校验机制？
对可执行文件进行数字签名，确保其自签名后未被篡改，保障软件完整性与来源可信。
苹果为何采用签名校验？
用于识别应用签署者身份，并验证应用是否被修改，从而防止恶意篡改与未经授权的分发，强化生态管控。
苹果如何实现签名校验？
理解非对称加密、数字签名与数字证书是掌握iOS签名机制的基础。本文将从通信安全出发，逐步解析加密体系，并结合苹果开发者证书生成流程与签名校验机制，全面揭示其技术原理。
主要内容包括：
1. 加密与解密、数字签名、数字证书在通信中的作用
2. 苹果开发者证书的生成与安装流程
3. iOS签名校验流程及关键组件解析
加密与解密、数字签名、数字证书的作用
无论是从App Store下载应用，还是通过Xcode调试安装，本质上都是一次设备间的通信过程。此类通信面临四大安全风险：
明文传输易被窃听 —— 被窃听 数据在传输中被篡改 —— 被篡改 第三方冒充发送方请求 —— 被欺骗 发送方事后否认行为 —— 被否认
防止被窃听：加密与解密
为防止信息泄露，需对数据加密。主流加密算法分为两类：
对称加密：加密与解密使用同一密钥，速度快，常见算法有DES、3DES、AES。
非对称加密：密钥分为公钥与私钥。公钥加密仅私钥可解，私钥加密仅公钥可解，典型算法为RSA。
对称加密密钥管理复杂，非对称加密性能较差。实际应用中多采用混合加密方案：
发送方：1. 使用对称密钥（如AES）加密数据；2. 使用接收方公钥加密该对称密钥；3. 合并发送。
接收方：1. 使用私钥解密获取对称密钥；2. 使用该密钥解密原始数据。
防止被否认：数字签名
由于公钥公开，任何人均可使用，无法确认发送者身份。利用非对称加密特性——私钥唯一持有，可通过发送方私钥加密摘要实现身份绑定，即数字签名。
数字签名三大作用：
1. 确认消息完整性
2. 验证内容未被篡改
3. 防止发送者抵赖
但前提是：公钥必须真实属于声称的持有者。若公钥被伪造，整个验证体系失效。
如何确保公钥合法性？
若继续用数字签名保护公钥，则陷入无限循环。为此，引入权威机构——证书中心（CA）。
保证公钥合法性：数字证书
由受信任的CA机构使用其私钥对用户公钥进行签名，生成数字证书。用户通过CA公钥验证证书，即可确认公钥归属。
流程如下：
1. 用户生成密钥对，提交公钥及身份信息至CA；
2. CA验证身份后，使用自身私钥对用户公钥签名，生成证书；
3. 第三方通过CA公钥验证证书，确认用户公钥真实性。
以上为数字签名与证书基础原理。接下来结合该机制，解析苹果开发者证书的生成与安装流程。
苹果开发者证书的生成与安装
苹果开发者证书的创建过程正是基于上述公钥基础设施（PKI）体系。
步骤一：生成证书请求文件（CSR）
通过“钥匙串访问”生成密钥对（公钥M与私钥M），并使用私钥M签署生成CSR文件。该文件包含开发者信息与公钥M，私钥M保留在本地Mac。
步骤二：上传CSR并生成证书
登录苹果开发者平台，上传CSR文件。苹果服务器（作为CA）使用其私钥A对公钥M进行签名，生成开发者证书。
步骤三：下载并安装证书
将生成的.cer证书下载至本地并双击安装。钥匙串会自动将该证书与本地私钥M关联，形成完整的认证凭证。
苹果签名校验流程及关键信息
苹果通过双重签名机制确保每个安装的应用均经官方授权。整体流程如下图所示：
> 1. Mac生成密钥对（公钥M/私钥M），苹果生成密钥对（公钥A/私钥A），公钥A预置在iOS设备中；
> 2. 开发者上传公钥M至苹果服务器，苹果使用私钥A签名生成证书；
> 3. 开发者使用私钥M对App签名，并将证书打包进App；
> 4. 安装时，iOS使用公钥A验证证书，再用公钥M验证App签名，通过后方可安装。
然而，仅验证开发者身份不足以满足设备控制与权限管理需求。苹果通过以下机制实现精细化管控：
关于P12文件：团队协作开发
团队成员无需各自申请证书。开发者可将包含私钥M与证书的钥匙串项导出为.p12文件，供其他成员导入使用，实现签名权限共享。
关于Entitlements：权限管控
Entitlements是iOS沙盒环境的配置文件，定义App可使用的系统能力（如Push、iCloud、Sign in with Apple等）。Xcode在编译时自动生成或读取.entitlements文件，并将其嵌入签名内容中，确保权限配置不被篡改。
可通过security cms -D -i embedded.mobileprovision查看Provisioning Profile中包含的权限信息。
关于Provisioning Profile：设备与权限绑定
Provisioning Profile是由苹果CA签名的plist文件，包含App ID、设备UDID列表、有效期、Team ID、entitlements及证书等信息，是实现设备授权与权限控制的核心。
开发者在后台配置相关信息后，苹果使用私钥A签名生成Profile文件。Xcode自动下载并管理该文件，并将其打包为embedded.mobileprovision嵌入App。
安装时，iOS使用预置公钥A验证Profile签名，确认其合法性后，进一步校验：
- 设备UDID是否在允许列表中（Development类型）
- Bundle ID是否匹配App ID
- 权限配置是否符合entitlements要求
- 证书有效性及有效期
注意：设备限制仅适用于Development证书；Enterprise和Distribution证书可自由安装。有效期方面，Development与Enterprise证书过期将导致应用无法启动，而App Store分发的应用不受此限制。
关于可执行文件与资源的签名
Xcode使用私钥M对Mach-O二进制文件签名，并将签名嵌入文件中，确保核心代码完整性。
但App还包含图片、音视频等资源文件。为保障整体完整性，系统在打包时生成_CodeSignature目录，内含CodeResources文件。
CodeResources为plist格式，记录除Mach-O外所有文件的哈希值（sha1与sha256），用于安装时校验资源是否被篡改。
完整签名与校验流程
- Mac生成密钥对（公钥M/私钥M），苹果系统预置公钥A，私钥A由苹果服务器保管；
- 开发者上传CSR（含公钥M）至苹果服务器，苹果使用私钥A签名生成证书，并结合App ID、entitlements、设备UDID等信息生成Provisioning Profile；
- 开发者下载并安装证书与Profile，Xcode自动管理；
- 编译时，Xcode使用私钥M对App签名，并将Profile嵌入为
embedded.mobileprovision； - 安装时，iOS在临时沙盒接收数据，使用公钥A验证Profile签名，确认来源合法；
- 验证通过后，使用公钥M验证证书与App签名，校验设备ID、Bundle ID、权限配置及资源哈希值；
- 全部校验通过后，创建正式沙盒完成安装。启动时亦会执行校验，防止运行时篡改。