Gatekeeper信任开发者ID证书需满足三重条件：证书必须明确支持代码签名用途（EKU字段匹配）、在钥匙串中设为“使用系统默认设置”、且应用须经Apple公证；仅签名有效不足以默认放行，未公证应用仍会触发“无法验证开发者”警告。
gatekeeper 对开发者 id 签名证书的信任，不是简单“认不认”一个问题，而是依赖一套分层、可配置的验证逻辑。它不会无条件信任任何证书，而是严格检查该证书是否满足 代码签名 用途，并在运行时结合签名有效性、公证状态和系统策略共同决策。
核心信任条件：证书必须明确支持“代码签名”用途
并非所有 Apple 颁发的证书都能用于签名 macOS 应用。Gatekeeper 只接受被明确标记为可用于 代码签名（Code Signing） 的证书。关键判断依据是证书的“扩展密钥用法（Extended Key Usage, EKU）”字段是否包含 1.3.6.1.4.1.311.10.3.12（Microsoft Code Signing）或苹果认可的等效标识。
常见错误情况包括：
- 误用了仅用于开发调试的 iOS Development 或 Mac Development 证书（它们不支持分发）
- 使用了过期、被吊销或未正确安装到“系统”钥匙串的 Developer ID 证书
- 证书虽存在，但在钥匙串中未设置为“始终信任”其 代码签名 策略
证书在钥匙串中的信任策略设置
即使证书本身有效，Gatekeeper 仍会读取其在“钥匙串访问”中为 代码签名 用途指定的信任策略：
- 使用系统默认设置：系统按标准规则判断，通常要求证书链完整、未过期、未吊销，且用途匹配
- 总是信任：强制系统接受该证书用于代码签名（仅建议用于内部测试证书，不推荐对正式 Developer ID 设置此项）
- 永不信任：即使证书合法，Gatekeeper 也会拒绝其签名的应用（可用于临时屏蔽某开发者）
操作路径：打开“钥匙串访问” → 在“登录”或“系统”钥匙串中找到你的 Developer ID 证书 → 双击打开 → 展开“信任” → 在“代码签名”下拉菜单中选择“使用系统默认设置”（生产环境首选）。
签名有效性 ≠ Gatekeeper 放行：公证才是关键一环
仅用有效的 Developer ID 证书签名，不足以让 Gatekeeper 默认放行双击启动。从 macOS 10.15 起，Gatekeeper 还要求应用通过 Apple 公证服务（Notarization）。这是因为签名只证明“谁签的”，而公证证明“苹果扫描过，没发现恶意行为”。
未公证的应用，即使签名完全正确，用户首次双击时仍会看到“无法验证开发者”警告。此时 Gatekeeper 实际执行的是：签名有效 + 但未公证 → 触发用户确认流程，而非直接拒绝。
如何验证证书与签名是否符合 Gatekeeper 要求
终端命令是最可靠的自查方式：
- 查证书是否存在且可用：
security find-identity -p codesigning -v（应列出你的 Developer ID Application 证书） - 查应用签名完整性：
codesign -dv /path/to/App.app（关注TeamIdentifier、Authority是否匹配，Signature size是否非零） - 查是否已公证：
spctl -a -t exec -v /path/to/App.app（返回“accepted”表示本地策略允许；若提示“rejected”且含 notarization 相关字眼，则需补公证）
