Home

深色模式

Apple开发相关的证书 ​

概述 ​

Apple 开发相关证书分别承担代码签名、服务身份认证、支付数据保护、资源签名和信任链验证等工作。开发证书与发布证书只覆盖其中一部分；推送证书、支付证书和 Developer ID 都有独立的使用范围。

证书将公钥与身份及用途关联起来，实际签名或解密通常还需要对应私钥。以下按用途分类，逐项说明 Apple Developer 后台常见证书及相关信任链证书，资料查阅日期为 2026-10-09。

证书分类 ​

按开发工作中的用途，可以归纳为五类。这是便于理解的分类，不是 Apple 后台菜单的原样划分。

类别解决的问题主要类型
开发签名开发阶段由谁签名，在设备上运行和验证能力Apple Development、iOS Development、Mac Development
分发签名通过什么渠道发布应用或安装包Apple Distribution、Mac App Distribution、Mac Installer Distribution、企业分发证书、Developer ID
服务认证服务端如何连接 Apple 服务或保护业务数据Apple Push Services、VoIP Services、WatchKit Services、Apple Pay 相关证书
资源签名如何验证凭证、软件包等资源的来源，或完成专用分发流程Pass Type ID、Website Push ID、Swift signing、MDM Vendor CSR signing、ALD
信任链如何确认开发者证书由受信任的机构签发WWDR、Developer ID 中间证书、Apple 根证书

部分证书兼有多种作用。例如 Website Push ID 既用于签网站推送包，也参与推送服务认证。分类看主要用途，不能据此互换证书。

开发签名 ​

Apple Development ​

Apple Development 是现代 Xcode 工作流中的统一开发证书，覆盖 iOS、iPadOS、macOS、tvOS、visionOS 和 watchOS。它用于开发阶段的设备运行、调试和能力验证，不用于提交 App Store 分发。

开发证书属于个人开发者。组织团队成员可以在各自的 Mac 上创建开发身份，私钥保存在本机；团队不需要让所有开发者共用一份私钥。

以 iOS 真机调试为例，需要同时具备：

  • Apple Development 证书及对应私钥。
  • 匹配 App ID 和能力配置的开发描述文件。
  • 描述文件中包含目标设备的 UDID。

证书不会单独决定 App 可以装到哪些设备。开发签名身份有效，但设备没有加入 profile，仍可能无法安装。

Debug、Release 是构建配置，与证书类型是不同维度。使用 Release 优化编译的包，也可以按开发签名流程安装到注册设备；选择 Release 不会自动获得商店分发资格。

iOS Development ​

iOS Development 是较早的平台专用开发证书，用于 iOS、iPadOS、tvOS 和 watchOS 的开发运行。旧项目、旧 CI 配置和历史教程中仍可能出现这个名称。

它与 Apple Development 承担相似的开发用途，但证书类型和支持范围不同。现代项目通常使用统一开发证书；维护旧项目时，应确认 Xcode 与 profile 的实际配置，不要仅因名称较旧就删除现有签名资源。

Mac Development ​

Mac Development 用于 Mac 应用开发阶段的签名与部分服务能力验证。它不承担 Mac App Store 提交，也不替代官网分发所需的 Developer ID。

macOS 允许运行多种形式的本地开发代码，并非每个本地 Mac 程序都必须申请开发证书。需要受限能力、团队签名身份或特定签名验证流程时，再按项目配置使用开发身份。

分发签名 ​

Apple Distribution ​

Apple Distribution 是现代 Xcode 工作流中的统一发布证书，用于指定设备的测试分发，以及向 App Store Connect 提交应用。发布证书属于团队，常规本地证书由 Account Holder 或 Admin 创建。

同一发布身份可以用于团队内多个 App。具体签哪个应用、带哪些能力、走哪种分发渠道，还要配合描述文件等资源。

以 iOS 为例，常见配套关系是：

分发方式描述文件是否登记测试设备
Ad HocAd Hoc profile是，设备必须包含在文件中
TestFlightApp Store Connect profile否，通过 TestFlight 分发
App StoreApp Store Connect profile否，通过商店分发

TestFlight 走发布签名流程。 不存在需要单独申请的“TestFlight 证书”。Ad Hoc 与 App Store 的差异主要在 profile 和分发流程，不能当作两种不同的发布证书。

App Store 签名的 .ipa 用于提交给 Apple，不能因为没有设备列表就直接安装到任意 iPhone 上。

开发者会员资格有效时，已上架 App 不因上传所用发布证书过期而停止正常分发，但新版本必须使用有效身份签名。撤销证书还可能使已上传、尚未提交审核的构建被标记为无效二进制。

iOS Distribution ​

iOS Distribution 是较早的平台专用发布证书，用于 iOS 系列平台的 Ad Hoc 测试和商店提交。旧签名配置中常见此名称，现代普通分发流程通常使用 Apple Distribution。

它仍需匹配发布描述文件，不能替代开发证书完成日常真机调试。看到钥匙串中的 iOS Distribution，也不能只凭名称判断是否具备企业内部使用的授权，还需确认开发者计划与分发资源。

Mac App Distribution ​

Mac App Distribution 用于 Mac App Store 应用的代码签名，签的是应用本身。现代工作流也可能使用 Apple Distribution，具体取决于 Xcode 和项目的提交配置。

它与 Developer ID Application 的区别在分发渠道：前者面向 Mac App Store，后者面向商店外分发。Mac App Distribution 不能直接替代 Developer ID 来完成官网软件的签名与公证流程。

Mac Installer Distribution ​

Mac Installer Distribution 用于提交 Mac App Store 的安装包签名，签名对象通常是 .pkg。安装包内部的应用，仍需使用适用的应用签名身份。

应用代码签名与安装包签名是两项工作。给 .pkg 签名不会自动补齐包内 .app 的代码签名；Mac Installer Distribution 也不用于站外安装包，后者使用 Developer ID Installer。

企业分发证书 ​

企业分发证书用于 Apple Developer Enterprise Program 的内部使用场景。后台创建入口使用 In-House and Ad Hoc 选项；内部包还需要匹配的 In-House 描述文件。

它允许按企业内部授权范围分发，不依赖逐台登记 UDID，但这不代表可以向公众分发消费级 App。普通 Apple Developer Program 的公司团队，也不会仅因账号主体是公司就自动拥有 In-House 分发资格。

企业包对签名资源的有效性有运行依赖。证书过期或被撤销，已部署应用会受到影响，需要重新签名并分发。因此，不能直接套用“商店已上架 App 不受发布证书过期影响”的结论。

Developer ID Application ​

Developer ID Application 用于 Mac App Store 以外的应用代码签名，例如从官网下载安装的 Mac App。它为 Gatekeeper 提供开发者身份和代码完整性验证所需的信息。

站外分发通常还需要公证（notarization）。签名用于标识签名者并校验完整性，公证是 Apple 对提交软件进行安全检查的流程；持有证书不等于软件已经通过公证。

Developer ID 只服务于相应的 macOS 分发场景，不是 iOS 侧载证书。 使用 CloudKit 等高级能力的 Mac App，还可能需要 Developer ID 描述文件。

证书过期与被撤销的后果不同。有效期内正确签署的既有版本，可以在符合验证条件时继续使用；新版本需要有效证书。关联的 Developer ID profile 也必须有效，撤销证书则可能影响既有应用的安装与运行。

Developer ID Installer ​

Developer ID Installer 用于 Mac App Store 以外的 .pkg 安装包签名。它与 Developer ID Application 常成对使用：前者签安装包，后者签包内应用。

直接分发 .app 时不必为此额外申请 Installer 证书；只有使用需要相应签名的安装包流程时才涉及它。.dmg、.app 和 .pkg 是不同对象，不应因为都是下载产物就统一套用 Installer 证书。

安装验证还会涉及可信时间戳与证书状态。轮换时应分别验证安装包和包内应用，不能只检查 .app 的签名就认为整个分发包已经合格。

服务认证 ​

Apple Push Services ​

Apple Push Services 用于推送服务端通过证书认证连接 APNs。它证明推送服务端有权为关联应用发送通知，通常与具体 App ID 关联。

采用证书认证时，服务端需要证书及对应私钥；这些资源不应打进客户端 App。客户端仍需开启 Push Notifications capability，并使用包含相应 entitlement 的签名配置。

一张推送证书不能当作所有 App 通用的发布证书，也不能代替客户端的开发或发布身份。证书失效会中断对应的推送发送能力，并不意味着 App 代码签名同时失效。

APNs 还支持 token 认证，使用 APNs Auth Key 对应的 .p8 私钥签发 JWT。它是证书认证的替代方案，不是另一种 App 签名证书；当前密钥有环境和 topic 范围之分，接入时要核对实际配置。

VoIP Services ​

VoIP Services 用于服务端通过 APNs 向关联的 VoIP 应用发送通知，例如提醒应用处理呼入事件。申请时选择对应 App ID，并准备 CSR。

它参与 VoIP 推送服务的认证，不签 App，也不授予任意后台运行能力。客户端的 VoIP 处理和服务端认证是两部分，申请证书并不能代替客户端实现。

WatchKit Services ​

WatchKit Services 用于通过 APNs 推送更新 Apple Watch 的 ClockKit 表盘复杂功能数据。证书关联 App ID，由发送更新的服务端使用。

它不等于 watchOS 开发证书或发布证书，也不是所有 Watch App 的必备资源。是否需要它，应依据项目采用的表盘复杂功能 API 和更新机制确认。

Apple Pay付款处理 ​

Apple Pay Payment Processing 证书与 Merchant ID 关联，用于保护 Apple Pay 支付数据。Apple Pay 使用证书中的公钥加密支付信息，商户或支付服务商使用对应私钥解密并处理支付。

私钥由谁持有，取决于实际支付接入方案。接入支付服务商时，应使用服务商要求的 CSR 和配置流程，避免生成了一张证书，却没有让负责处理支付的一方持有匹配私钥。

这张证书保护支付数据，不给 App 签名，也不等于 StoreKit 内购凭据。当前官方文档列出的有效期为 25 个月，必须在到期前完成轮换；失效会影响使用它的支付交易。

Apple Pay商户身份 ​

Apple Pay Merchant Identity 证书用于网页 Apple Pay 与 Apple 服务器之间的身份认证。网站后端使用证书及私钥完成相应的商户验证通信。

它与 Payment Processing 分工不同：Merchant Identity 负责认证商户身份，Payment Processing 负责支付数据保护。网页接入通常还需配置 Merchant ID 和域名验证。

仅接入原生 App 的 Apple Pay，不需要因为“用了 Apple Pay”就额外申请网页商户身份认证证书。网页后端使用的私钥也不应交给浏览器。

资源签名 ​

Pass Type ID ​

Pass Type ID 证书用于签署 Wallet 中的票券、登机牌、优惠券等凭证，并支持凭证更新。申请前先注册 Pass Type ID，证书与该标识关联。

签名对象是 Wallet 凭证，例如 .pkpass，不是承载业务的 App。生成凭证的服务需要对应私钥，客户端则按 Wallet 能力配置访问或添加凭证。

证书过期后，已安装的凭证可以继续正常使用，但无法再用失效身份签署新凭证或发送更新。撤销证书的影响更大，不能把过期与撤销视为同一种轮换操作。

Website Push ID ​

Website Push ID 证书用于基于 Website Push ID 的 Safari 网站推送流程：签署网站推送包，并从网站服务器向 macOS 用户发送通知。它关联网站推送标识，而不是原生 App 的 Bundle ID。

这套流程应与标准 Web Push 区分。现代 Safari 的标准 Web Push 不要求加入 Apple Developer Program，也不要求申请此类网站推送证书；选型前先确认使用的是哪套接口。

Swift signing ​

Swift signing 证书用于 Swift Package Manager 5.9 及以后支持的包与包集合签名，帮助使用方验证分发资源的签名身份。

它面向依赖资源的发布与验证，不赋予 App Store 提交资格。给包签名后，消费该包的 App 仍需按自己的开发或分发流程完成代码签名。

MDM Vendor CSR signing ​

MDM Vendor CSR signing 证书用于 MDM 服务商签署自己或客户的 CSR，让客户随后申请 MDM Push Certificate。它需要向 Apple 申请相应访问资格，不是普通 App 开发必须创建的证书。

这里有两个不同的身份：服务商持有 CSR 签名证书，客户的设备管理服务持有最终的 MDM 推送证书及私钥。服务商不应把自己的 CSR 签名私钥分发给客户，也不能用它直接替代客户的推送身份。

App License Delivery ​

App License Delivery（ALD）包含签名与加密证书，用于符合资格应用的许可请求流程。获授权的替代应用市场可使用这类资源完成相应分发工作。

签名证书与加密证书各有用途，官方申请流程要求分别提交独立 CSR，并安全保存相关密钥。它们是专用许可交付资源，不替代应用自身的代码签名，也不是普通 TestFlight 或 App Store 发布必须申请的证书。

信任链 ​

WWDR中间证书 ​

Apple Worldwide Developer Relations（WWDR）中间证书用于连接相应开发者证书与 Apple 信任链。开发、发布及部分服务证书的验证会涉及它。

WWDR 不是项目自己的签名身份，开发者无需为每个 App 申请一张，也不持有它的签发私钥。不同用途可能对应不同 WWDR 中间证书，应使用与实际证书链匹配的版本。

签名证书已经安装，但仍显示不受信任时，应检查有效期、中间证书和根信任链。重复创建发布证书，无法替代缺失的中间证书。受支持的 Xcode 版本会安装相应中间证书，也可以从 Apple 官方 PKI 页面获取。

Developer ID中间证书 ​

Developer ID Application 与 Developer ID Installer 使用相应的 Developer ID 证书链。它与 WWDR 都属于信任链资源，但不能因为同由 Apple 提供就随意互换。

维护旧构建机器或导入 Developer ID 身份时，除证书与私钥，还应确认签发者对应的中间证书可用。Apple 调整签发机构后，旧、新身份可能涉及不同中间证书。

当前官方文档明确指出，原 Developer ID 签发机构将于 2027-02-01 到期；之后它签发的证书不能继续用于签名，应换成当前 G2 签发机构的证书。判断是否受影响要检查证书签发者，不能只看名称或到期时间。

Apple根证书 ​

根证书是信任链的起点，由系统或验证环境作为信任锚使用。中间证书和开发者证书逐级连接到受信任的根，才能完成相应验证。

它不属于团队自行申请的证书，也不提供团队签名能力。通常由操作系统维护；不要为了绕过签名错误，随意把未知证书设为始终信任。

配套资源 ​

私钥与文件 ​

证书文件和可用签名身份有区别。本地代码签名身份由证书与对应私钥共同组成；只从 Apple 后台下载 .cer，无法找回丢失的私钥。

文件作用是否属于证书
.cer常见的 Apple 签发证书文件，不含私钥是
.certSigningRequest申请证书的 CSR，包含公钥等信息否
.p12可打包导出证书与对应私钥，通常设置密码是容器，可能包含证书和私钥
.mobileprovisioniOS 描述文件，约束应用、签名身份、能力和运行范围否
.p8APNs、Sign in with Apple 或 API 等场景使用的私钥文件否

换 Mac 或迁移 CI 时，使用本地签名的流程需要迁移完整身份，而不是只迁移 .cer。.p12、.p8 及其密码应进入受限的密钥管理系统，不提交 Git，不打进 App。

描述文件 ​

iOS 描述文件关联证书、App ID、entitlements、有效期和设备或分发范围。开发 profile 可以关联多个开发证书，App Store profile 关联一个发布证书。

新增设备、换用新证书或修改 App ID 能力后，手工管理的 profile 要相应更新。证书、profile 和开发者会员资格各有有效期，应分别检查。

macOS 的授权规则不同，不能把 iOS 的 profile 要求直接套到所有 Mac 软件上。

签名管理 ​

Xcode 自动管理签名与手动管理签名，区别在于由谁准备、选择和更新签名资源。两者最终都要使用有效身份和匹配的授权资源，产物遵守相同的签名规则；手动签名不会多出一种证书，也不会获得更高的分发权限。

管理边界 ​

对比项自动管理手动管理
签名身份Xcode 按需选择或创建，受账号权限约束团队准备身份并控制构建使用哪一份
描述文件Xcode 管理、选择和更新所需 profile团队生成并为目标指定 profile
设备变化在权限允许时注册设备、更新管理的 profile登记设备后，重新生成并分发 profile
能力变化Xcode 同步可管理的 App ID 能力与 profile在后台配置 App ID，再更新 profile 和项目
远端依赖创建或修复资源时，需要有效认证及网络连接资源已准备完整时，本地签名可以不访问后台
维护重点团队、权限、账号状态与实际选用的资源身份、profile、能力、设备与有效期的一致性
典型场景日常真机开发，允许 Xcode 管理资源的分发或 CI集中管理凭据、限制后台变更、固定发布资源的流水线

自动签名也可以复用已存在的资源，并非每次构建都申请新证书。手动签名也可以由脚本分发资源，“手动”指资源选择与维护由团队控制，不代表每次都要在网页上点击。

自动签名 ​

常见配置流程是：

  1. 在 Xcode 的账号设置中登录 Apple Account，确认能访问目标团队。
  2. 选择应用 target，进入 Signing & Capabilities，选择正确的 Team。
  3. 设置 Bundle ID，开启 Automatically manage signing。
  4. 添加所需 capabilities，连接真机或进入归档分发流程。
  5. 检查 Xcode 显示的签名状态，确认所用身份和 profile 与用途匹配。

开发阶段，Xcode 可以按需创建签名身份、注册应用标识和设备、更新其管理的 profile。添加能力时，它也可以同步支持自动配置的 App ID 设置；需要 Apple 单独批准或额外服务端配置的能力，仍要完成相应流程。

主 App、Widget、通知服务扩展等需要独立授权的 target，必须分别配置正确的 Bundle ID 和签名。只对主 App 勾选自动管理，不能保证整个工程中的扩展都已配置完成。

自动签名始终受权限约束。组织可以通过 Automatic Signing Controls 限制 Developer 角色注册 App ID、注册设备或修改 App ID。遇到权限错误，应由管理员提供资源或调整授权，反复勾选开关不会绕过限制。

Xcode 自动创建的本地身份仍有私钥。换机器时，新机器可以按权限创建自己的开发身份；必须使用既有身份的流程，则需要迁移对应私钥，重新下载 .cer 不能代替这一步。

手动签名 ​

以 iOS 真机包为例，团队需要先准备完整资源，再配置项目：

  1. 在 Apple Developer 后台确认 App ID、Bundle ID 和启用的能力。
  2. 创建或复用适用的开发／发布证书，在构建机器上安装证书与对应私钥。
  3. 选择开发、Ad Hoc 或 App Store Connect 类型，生成关联正确证书的 profile；开发和 Ad Hoc 还要包含目标设备。
  4. 下载并安装 profile，在 target 的 Signing & Capabilities 中关闭 Automatically manage signing。
  5. 为对应构建配置选择匹配的 Provisioning Profile，检查显示的团队与签名身份。
  6. 为需要独立 profile 的扩展分别完成配置，并验证整个 App 的签名与能力授权。

项目中的关键设置通常包括 CODE_SIGN_STYLE = Manual、DEVELOPMENT_TEAM、CODE_SIGN_IDENTITY 和 PROVISIONING_PROFILE_SPECIFIER。它们可能来自 target、项目、.xcconfig 或命令行覆盖，应检查最终生效值，避免界面已改为手动，CI 却仍传入自动签名配置。

手动管理需要维护资源关联关系。证书换新、增加设备或修改能力后，更新相关 profile，并确保本地与 CI 使用同一批有效资源。选择一个名称看似正确的旧 profile，仍可能出现证书、设备或 entitlements 不匹配。

手动签名也不必把所有开发者变成管理员。团队可以由少数有权限的成员创建发布资源，再通过受限渠道提供给构建流程；开发者按自己的权限使用开发身份。

归档与导出 ​

构建归档和导出分发是两个签名阶段。日常开发采用自动管理，不意味着导出 Ad Hoc 或商店包时只能继续使用同一种管理方式；导出阶段会按分发用途选择资源并重新签名。

命令行导出的 ExportOptions.plist 中，signingStyle 控制分发阶段的自动或手动签名；手动导出可使用 provisioningProfiles 为各可执行目标指定 profile，使用 signingCertificate 指定签名身份。主 App 与扩展的 Bundle ID 不同，需要相应映射，不能只提供主 App 的 profile。

归档方式能否切换到另一种导出方式，还受 Xcode 版本约束。部分旧版文档要求手动签名的归档继续手动导出；本文核对的 Xcode 27.0 xcodebuild -help 已允许手动归档选择自动分发，但该流程不会注册设备、注册 App ID 或修改 App ID 设置，只会按需创建 profile 和托管云签名证书。

维护流水线时，应以实际安装版本的帮助为准，不能只根据 Debug、Release 或工程中的一个开关推断最终发布身份：

sh
xcodebuild -help

CI使用 ​

自动签名可以用于 CI，前提是提供适用的认证、网络和团队权限。xcodebuild 的 -allowProvisioningUpdates 允许访问开发者后台：对自动签名目标，它可以创建或更新 profile、App ID 和证书；对手动签名目标，它可以下载缺失或更新后的 profile。

需要命令行登记目标设备时，还要使用 -allowProvisioningDeviceRegistration，且必须同时允许 provisioning updates。允许访问后台不代表账号获得了额外权限，这些参数也不会自动修复丢失的本地私钥。

固定发布资源的 CI 通常由团队预先安装签名身份和 profile，并明确各目标的配置。这样可减少构建期间的远端资源变更，但证书轮换、profile 更新、钥匙串解锁及私钥访问权限，都要纳入流水线维护。

自动或手动模式都不能保证签名输入永久不变。需要审计发布结果时，应记录实际使用的证书、profile、团队与分发方式，而不是只记录“使用自动签名”。

与云签名的区别 ​

自动／手动管理讨论的是资源如何选择和维护，云／本地签名讨论的是签名身份由哪里管理、签名如何完成。两组概念有关联，但不是同一个开关。

Xcode 13 及以后，在受支持的 Organizer 归档分发流程中，本地没有可用发布身份时，可以在具备权限的前提下使用云托管身份。开启自动管理并不代表所有构建都在云端签名，xcodebuild 也不能仅凭自动模式就被视为无需本地身份。

云托管身份不能当作本地 .p12 随意导出迁移；使用本地签名的 CI，仍需完整身份。普通网站 HTTPS 证书、APNs 推送服务私钥和 Apple Pay 服务端证书，也不会因为开启 App 自动签名就全部得到配置。

常见问题 ​

现象自动管理优先检查手动管理优先检查
找不到签名身份账号、团队权限、本地身份及流程是否支持云签名对应私钥是否存在，钥匙串是否可访问
profile 不匹配所选团队和 Bundle ID、远端权限、是否残留手动配置所选 profile 的 App ID、证书与 entitlements
新设备无法安装是否允许注册设备，管理的 profile 是否已更新设备是否登记，并包含在新生成的 profile 中
主 App 能签，扩展失败扩展 target 的团队、Bundle ID 与签名模式扩展的独立 profile 和导出映射是否完整
本地成功，CI 失败CI 认证、网络及 provisioning updates 参数CI 资源版本、配置覆盖、钥匙串解锁与权限

参考 ​