尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

App-Store-Connect-CLI 签名身份同步(Signing Identity Sync)实战指南:把本地私钥与证书配对加密存入共享仓库

发布时间:2026/9/29 7:11:04

资讯中心
01
ARTICLE

App-Store-Connect-CLI 签名身份同步(Signing Identity Sync)实战指南:把本地私钥与证书配对加密存入共享仓库

App-Store-Connect-CLI 签名身份同步(Signing Identity Sync)实战指南:把本地私钥与证书配对加密存入共享仓库
【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载asc signing sync push是 App-Store-Connect-CLI 中负责共享可用的签名身份的核心命令。本指南围绕该命令新增的私钥身份同步能力展开它如何把本地的 PKCS#12 或 RSA/EC 私钥与所选 provisioning profile 内嵌的证书配对加密为一份规范身份canonical identity存入 Git 仓库或其他远端存储供其他 Agent 与 CI worker 通过sync pull解密使用同时讲解 5.0 之后唯一的密码来源--password-file与ASC_SIGNING_SYNC_PASSWORD以及 profile 生命周期管理续期、设备刷新、按类型清空。读完本文你将掌握端到端配置加密签名身份仓库、在多台机器间安全同步私钥、以及从 4.x 迁移到 5.0 的完整方法。核心能力signing sync push现在可以同步私钥身份按照 commands/signing.mdx 的说明Apple 代码签名由四部分组成bundle ID、证书公钥、provisioning profile以及运行 Xcode 的机器上同时存在的私钥与 profile。App Store Connect 只能创建并返回证书永远无法返回私钥因此团队内共享私钥必须依赖外部机制。从版本 4.x 开始asc signing sync push在原有证书 profile同步的基础上新增了私钥身份同步能力设计文档见 docs/design/signing-private-identity-sync.md把本地提供的 PKCS#12 或 RSA/EC 私钥与所选 profile 内嵌的证书配对校验它们属于同一身份后加密成一份规范化的、密码保护的 PKCS#12每个团队/证书只存一份私钥材料并绑定 team、bundle、profile 类型、证书与经过验证的 profile 的认证上下文记录其他机器或 CI worker 用asc signing sync pull解密出可直接使用的.p12。这一扩展不新增第二个签名存储库也不暗示 App Store Connect 能返回私钥——所有私钥材料都来自显式的本地输入。两种私钥输入方式# 方式一PKCS#12.p12身份 asc signing sync push \ --bundle-id com.example.app \ --profile-type IOS_APP_ADHOC \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --identity ./distribution.p12 \ --identity-password-file ~/.config/asc/distribution-p12-password # 方式二与 CSR 一起生成的 RSA/EC 私钥PEM asc signing sync push \ --bundle-id com.example.app \ --profile-type IOS_APP_ADHOC \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --private-key ./distribution-key.pem \ --identity-sha256 64-hex-ASC-certificate-fingerprint # 方式三macOS 直接分发Developer ID asc signing sync push \ --bundle-id com.example.mac \ --profile-type MAC_APP_DIRECT \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --identity ./developer-id-application.p12 \ --identity-password-file ~/.config/asc/developer-id-password参数规则源码中的 flag 解析与校验见 internal/cli/signing/signing_sync.go--identity与--private-key互斥同时传是用法错误exit 2测试用例TestSigningSyncPushInvalidIdentityCombinationUsesUsageExitCode明确断言了这一点internal/cli/cmdtest/signing_sync_identity_test.go一个 PKCS#12 包含多个私钥身份时必须用--identity-sha256指定证书指纹来选择--private-key总是要求--identity-sha256这样在一把密钥被重签reissue时远端证书的选择是显式而非猜测的PKCS#12 的原始密码只能通过--identity-password-file传入源码要求该文件必须为受保护的常规文件见 signing_sync.go无密码保护的 PKCS#12 不需要该参数。macOS 直接分发Direct Distribution支持私钥身份同步同样支持MAC_APP_DIRECT与MAC_CATALYST_APP_DIRECT。命令要求App Store Connect 返回的精确活动 profile 类型、profile 中签名的 macOS 平台声明与 all-device 声明接受两个受支持代数generation的 Developer ID Application 证书并在发布前把本地私钥、API 证书、profile 内嵌证书、team、bundle ID、签名后的 profile 作为一个整体身份校验。设计文档记录了对把每个签名过的 all-device profile 都当作直接分发类型方案的拒绝理由——all-device 声明无法区分原生 Mac 与 Mac Catalyst且被其他分发家族共用最终以 API 资源的精确profileType作为原生 Mac 与 Mac Catalyst 的判别器以签名 profile 与关联的 Developer ID 证书提供密码学绑定signing-private-identity-sync.md。仓库密码的来源只有--password-file与ASC_SIGNING_SYNC_PASSWORD加密签名仓库需要一个高熵仓库密码。4.x 时代按以下顺序解析见 signing-private-identity-sync.md--password-file必须指向一个不跟随符号链接no-follow的常规文件且仅属主可读显式的旧版--password标志打印弃用警告ASC_SIGNING_SYNC_PASSWORD环境变量旧版ASC_MATCH_PASSWORD环境变量打印弃用警告。在 5.0.0 中后两个旧来源已被彻底移除--password不再注册未注册的标志直接以 exit 2 失败ASC_MATCH_PASSWORD不再被读取见 migrate-to-5-0.mdx 的Encryption password sources与Removed environment variables两节。当前唯一合法的密码来源是# 本地工作推荐受保护的密码文件 asc signing sync pull --repo gitgithub.com:team/signing.git \ --password-file ./signing-password.txt # CI/密钥托管环境推荐环境变量 export ASC_SIGNING_SYNC_PASSWORD$(cat /run/secrets/signing-sync-password)两条规则源码resolveSyncPassword见 signing_sync.go密码文件必须是常规文件、不得是符号链接、不得被 group 或其他用户访问建议chmod 600文件末尾的一个 LF 或 CRLF 会被去除剩余密码不能为空。命令输出stdout只写结构化数据进度与弃用警告写到 stderr非法标志组合使用 exit 2运行期失败使用 exit 1。任何 JSON、诊断信息或错误中都不会出现密码或身份数据。加密格式scrypt 派生密钥 AES-256-GCM 认证元数据signing sync的所有.enc加密工件都使用AES-256-GCM认证加密同时提供机密性与完整性文件被篡改或密码错误都会解密失败。区别在于密钥派生与信封格式源码见 internal/signing/encrypt.go新式版本化信封identity 与新版 profile 工件用 scrypt 派生 32 字节密钥参数为N32768, r8, p1源码常量见 encrypt.go信封布局为magic ASCENC || 元数据长度 || 元数据 JSON || salt(16B) || nonce(12B) || ciphertexttagJSON 元数据头作为 AES-GCM 的 additional authenticated dataAAD绑定进认证。也就是说一旦有人改动了记录中的相对路径、资产种类kind、sensitivity 标志、证书 SHA-256、team、bundle ID、profile 类型或 KDF 参数解密会像密文被篡改一样失败encrypt.go元数据结构见EncryptedFileMetadata身份元数据绑定路径、种类、敏感标志、证书指纹、team上下文元数据绑定 bundle 标识与 profile 类型profile 信封额外绑定 profile 资源 ID 与 UUIDencrypt.go工件大小有硬上限加密文件不超过 34 MiB、元数据不超过 64 KiBpull在调用 KDF 之前就限制每个工件、元数据头、工件数量与累计字节数encrypt.go。旧式 PBKDF2 格式兼容保留公开证书文件以及既有仓库中较老的未版本化 profile 文件保持稳定的 PBKDF2 格式PBKDF2-HMAC-SHA256、100,000 次迭代、16 字节 salt、32 字节密钥、无附加认证数据encrypt.go。DecryptFile对不带ASCENCmagic 的数据自动走旧路径返回零值元数据encrypt.go因此既有证书/profile 仓库仍然可读sync pull仍能解密旧文件。规范化 PKCS#12 与存储布局归一化后的工件恰好包含一个私钥及其匹配的证书使用 sync 密码保护为密码保护的 PKCS#12其现代互换兼容编码器使用 PBKDF2然后按 team/证书去重存储一次路径为identities/development-or-distribution/CERT_SHA256.p12.enc每个作用域scope只有一份认证的 current-context 记录profile 续期会原子推进该记录Git 历史保留先前状态不复制私钥材料每个有签名的 all-device profile 的上下文记录绑定 team、bundle、profile 类型、证书与精确验证过的 provisioning profileprofile 工件后缀区分平台macOS 原生类型用.provisionprofile.enciOS/tvOS 用.mobileprovision.enc既有旧路径仍然可读sync 不会隐式重命名它们。设计文档明确建议用生成的 32 字节随机高熵密钥作为 sync 密码而不是人类可记忆的口令signing-private-identity-sync.md。身份校验与发布边界fail-closed 原则推送私钥身份时命令执行一组严格的本地与远端校验任何一环不满足都会在发布前停止本地秘密输入打开时不跟随路径最后一个组件且必须是常规文件、无 group 或其他用户权限位PEM 输入接受 RSA 或 EC 私钥公钥匹配本地私钥的公钥必须匹配所选 profile 关联的一个活动、未过期的证书当需要创建 profile 时只有匹配的 App Store Connect 证书合格整体身份一致性下载的 profile、其内嵌开发者证书、API 证书、本地私钥作为一个身份检查同时校验 profile 过期时间与证书的 team 组织单元直接分发特判若 API 资源类型缺失或与--profile-type不一致、关联证书与本地私钥或 profile 内嵌证书不匹配、profile 的 team/bundle ID/状态/过期无效命令都会在发布前停止signing-private-identity-sync.md。此外push只写入一个隔离的临时 clone只有所有加密工件都成功发布后才 commit 并 push任何本地多文件写入失败都会在 Git commit 前返回并清理临时 clone因此不会把部分身份图谱推到远端仓库signing-private-identity-sync.md。若证书或 profile 创建成功但仓库发布失败JSON 输出是部分回执并报告publicationState: unknown重试前必须先检查commands/signing.mdx。Profile 生命周期管理续期、设备刷新与按类型清空发布说明文档docs/release-notes-signing-identity-sync.md明确列出了三个生命周期操作均要求 Git 存储--storage git使每次替换或删除都落在一个可审阅的 commit 中。详细命令参考见 commands/signing.mdx#renew-refresh-and-remove-synced-profiles。--renew-expired续期过期 profile仅当所选--profile-type没有活动 profile 时生效删除最近过期的 profile用活动、未过期的证书创建同名后继 profile并移除被取代的加密 profile。若存在活动 profile 则原样复用若既无活动也无过期 profile则报常规的 missing-profile 错误除非同时设置了--create-missing。--force-for-new-devices设备集变化后重建把开发/adhoc profile 的当前设备与--device指定的设备或该 profile 类型的所有已启用设备比较设备集未变则不动不同则删除并以同名同证书重建。其他 profile 类型传此标志直接 exit 2。--include-mac-in-profiles把 Apple silicon Mac 计入 iOS 设备集把已启用的 Apple silicon Mac 加入IOS_APP_DEVELOPMENT与IOS_APP_ADHOC设备集。App Store Connect 的 profile 上没有独立的包含 Mac属性所以该选项通过设备列表实现要求同时使用--force-for-new-devices且不能与--device组合。asc signing sync push \ --bundle-id com.example.app \ --profile-type IOS_APP_ADHOC \ --force-for-new-devices \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password推送回执会附加一个profileLifecycle对象多目标 JSON 中每个 target 一份包含actionunchanged、renewed或devices-refreshed、新旧 profile ID、replacedProfileState、devicesAdded与devicesRemoved。sync nuke按类型清空并吊销证书# 先预览不产生任何变更 asc signing sync nuke \ --profile-type IOS_APP_DEVELOPMENT \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --dry-run # 确认执行 asc signing sync nuke \ --profile-type IOS_APP_DEVELOPMENT \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --confirmsync nuke删除--profile-type的每一个profile吊销--certificate-type省略时从 profile 类型推断的每一个证书并在一个 commit 中移除它们的加密工件。注意其他类型的 profile 不会被删除但吊销一个共享的开发/分发证书会使所有内嵌它的其他 profile 失效。--dry-run打印计划且不做任何改动否则必须--confirm。Nuke 在任何 App Store Connect 变更前先认证整个仓库失败不会中断其余操作——回执逐条列出失败项未确认删除/吊销的工件保留命令最终 exit 1。拉取与消费pull、sensitiveFiles与identityPresent其他机器或 CI worker 用signing sync pull解密仓库mkdir -p .asc/signing chmod 700 .asc/signing asc signing sync pull \ --repo gitgithub.com:team/signing.git \ --password-file ~/.config/asc/signing-sync-password \ --output-dir .asc/signing/pulled \ --output json \ --pretty .asc/signing/pull-result.json # 敏感身份文件列表含私钥材料的输出 jq -r .sensitiveFiles[]? .asc/signing/pull-result.json需要记住的输出语义files列出所有解密输出包括私钥身份sensitiveFiles是其中含私钥身份材料的子集。不要把files当作非敏感清单——凡是同时出现在sensitiveFiles中的路径都必须排除或保护新写入的文件使用 mode0600普通输出也是0600而既有的证书/profile 输出在原子替换时保留原有模式identityPresent: false表示仓库里只有证书和 profile不能单独用于签名敏感身份信封是新增类型pull会拒绝不安全的身份信封、过大的仓库、路径逃逸以及与加密工件不匹配的元数据若要只解密一个应用上下文用--bundle-id--profile-type选择器一次调用一个 profile 类型选择器拉取会先认证并校验整个加密仓库再过滤输出因此未选中的损坏工件同样是错误。完整 CI 示例拉取 → 安装 profile → 安装专用 keychain → xcode 归档导出见 commands/signing.mdx#ci-example它在一个 shell 进程中完成所有秘密文件与 keychain 步骤用trap清理并设置GIT_TERMINAL_PROMPT0与GIT_SSH_COMMANDssh -o BatchModeyes防止 Git 子进程在 CI 上挂起等待输入。源码验证与测试覆盖仓库为这一功能提供了命令级测试证据可以按文件继续深入身份输入校验测试不存在、坏 PKCS#12、坏 PEM、缺密码文件、权限过宽、--identity/--private-key互斥等见 internal/cli/cmdtest/signing_sync_identity_test.go加密/解密与信封格式、旧格式兼容测试见 internal/signing/encrypt_test.goGit 存储往返与原子发布测试见 internal/signing/gitstore_test.go生命周期renew / force-for-new-devices / nuke命令级测试见 internal/cli/signing/signing_sync_lifecycle_test.go 与 internal/cli/signing/signing_sync_nuke_test.go。设计文档 signing-private-identity-sync.md 记录了完整的 RED-GREEN 验证矩阵公开 flag 校验与密码来源兼容、受保护的 no-follow 输入读取、RSA 与 EC 密钥、单/多身份 PKCS#12 解析、证书不匹配、profile/证书/team/过期检查、原生 Mac 与 Mac Catalyst 直接分发身份校验、规范化 PKCS#12 往返、版本化认证信封、旧信封读取、sensitiveFiles、0600pull 输出以及输出与错误中的秘密金丝雀secret canaries。直接分发扩展还增加了合成签名 profile 覆盖含缺失与非 macOS 平台声明拒绝以及本地身份失败仍是运行期错误而非用法错误的命令边界测试。从 4.x 迁移到 5.0 的注意事项如果你在 CI 脚本或内部 runbook 中固定了 4.x 的命令面升级前请对照 migrate-to-5-0.mdx 检查替换密码来源把所有asc signing sync push|pull ... --password ...改为--password-file PATH把ASC_MATCH_PASSWORD改为ASC_SIGNING_SYNC_PASSWORD5.0 中两者皆无会报missing--password-file的用法错误exit 2--device必须配--create-missing4.x 的警告并忽略行为在 5.0 变为硬用法错误signing fetch与signing sync push同样适用验证退出码与 stderr移除的标志未注册直接 exit 2--password的替代说明会出现在--help输出中。小结签名身份同步把证书 profile 共享扩展为证书 profile 私钥身份共享本地私钥与 profile 内嵌证书配对后归一化为单一规范的密码保护 PKCS#12以 scrypt AES-256-GCM 认证信封按 team/证书去重存储绑定完整上下文元数据并保持旧 PBKDF2 工件可读。配合--renew-expired、--force-for-new-devices、--include-mac-in-profiles与sync nuke的生命周期操作一个团队可以把完整的可签名身份安全地放进一个加密 Git 仓库或 S3/实验性远端存储让任意 Agent 与 CI worker 一键拉取使用。唯一要牢记的安全底线是仓库密码只来自受保护的--password-file或ASC_SIGNING_SYNC_PASSWORD私钥永远只从显式本地输入进入系统App Store Connect 无法也不应返回私钥。赞分享【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载相关推荐EUI 设计系统同步指南让 Figma Borealis 组件库与代码变更保持对齐EUI 设计系统同步指南让 Figma Borealis 组件库与代码变更保持对齐 EUIElastic UI作为支撑 Elastic 全线产品的开源组件App-Store-Connect-CLI 持久化签名钥匙串安装asc signing keychain install 设计解析与实战指南App Store Connect CLI 持久化签名钥匙串安装 asc signing keychain install 设计解析与实战指南 asc sigasc signing runApp Store Connect CLI 的临时签名执行环境Ephemeral Signing设计与实战asc signing runApp Store Connect CLI 的临时签名执行环境Ephemeral Signing设计与实战 导读 asc s上一篇免费开源虚拟歌手软件OpenUtau从入门到精通的完整指南下一篇OpenModScan免费开源Modbus调试工具5分钟上手工业通讯创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

◈

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

◐

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

▲

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。