1. 生产证书过期影响到底有多大先说一个我自己的情况一个维护了三年的线上App前两周Xcode突然在上传新版时弹出“Your account already has a valid iOS Distribution certificate”和“Certificate has either not been issued or has been revoked”这类报错。打开开发者后台一看生产证书状态已经变成了Expired。那一刻我第一反应是完蛋了线上用户是不是要受影响App是不是要下架结果冷静下来一查情况没那么恐怖但也不容忽视。苹果的iOS签名体系里生产证书Apple Distribution Certificate是给“上架版本”做代码签名的凭证。它过期了已经在App Store上架并正在被用户下载的App并不会被强制下架用户手上的App也照常能打开使用。因为签名验证发生在安装时而不是每次启动时。受影响的是你的“交付链路”传新包、发TestFlight、用Ad Hoc分发全部会卡在签名校验这一层。说得直白点老用户暂时没事但你想更新版本、想推送新Build给测试员这条路就被堵死了。还有一个容易被忽略的重灾区是推送。很多项目会把APNs的推送证书跟生产证书混为一谈其实它们完全不是同一个东西。生产证书负责代码签名APNs证书负责推送通道的TLS连接各自有独立的有效期。我见过最典型的翻车现场就是只更新了代码签名证书推送Retry一直失败查了半天才发现是APNs推送证书也在同一天到期。所以遇到“证书过期”这五个字第一步不是急着改而是先分清楚到底哪个证书过期了。另一个要提醒的点是Team账号的角色权限。更新生产证书不是谁都能做的需要Account Holder或者Admin权限。我有一回在客户公司帮忙维护对方只给了我一个App Manager账号我后台怎么都找不到创建证书的入口折腾半小时后客户换了个管理员账号才继续。所以动手之前先确认自己权限够不够省得流程走到一半被卡死。总体来看生产证书过期这件事的性质就是不致命但必须尽快处理而且处理步骤不能出错否则会影响团队的发布节奏。下面我就按自己实际操作过的完整顺序从证书检查、更新、Profile配置到Xcode设置一步一步讲明白包括中间踩过的坑。2. 更新前必须先搞懂的证书关系2.1 开发证书和生产证书有什么区别很多新手会把“证书”这个概念看得特别重但其实它在我们日常开发里只有两个出场场景本地调试和线上发布。开发证书iOS Development Certificate用于开发调试阶段配合开发描述文件让应用在真机上运行。生产证书Apple Distribution Certificate用于App Store、TestFlight、Ad Hoc三种分发方式它签署的是你准备交给苹果审核、或者分发给测试人员的版本。这两种证书在苹果开发者后台的“Certificates, Identifiers Profiles”里是分开管理的。创建的时候系统会让你选择用途比如iOS App Development、Apple Distribution、App Store Connect、Ad Hoc等选项。一个常见误区是以为只要在后台“一键续期”原来的证书就行——苹果后台没有“续期”按钮证书到期后只能“重新创建”。旧证书过期后可以从后台删除也可以保留到自然失效但不管怎样新证书必须通过生成新的CSR来申请。还有一点需要理解证书本身只是一份“可信身份证明”真正干活的是它对应的私钥。私钥留存在你生成CSR的Mac上存在系统钥匙串里。如果证书更新了但私钥丢失或者私钥在其他人的电脑上你的新证书就是一张废纸。所以后续流程里我会反复强调私钥的位置。2.2 证书和Profile的对应关系Provisioning Profile描述文件是连接“证书App ID设备”的配置文件。它会把你的开发/生产证书、Bundle ID、测试设备的UDID等信息打包在一起。手动签名模式下Xcode构建时会把描述文件里的证书扔给签名工具自动签名模式下Xcode会自己向开发者后台申请并下载匹配的描述文件。这里有一个很多人忽略的关键逻辑描述文件本身也有有效期而且它的有效期不能超过关联证书的有效期。当生产证书过期后旧描述文件即使日期上还没到期实际也已经不能用了因为签名时系统会发现文件里的证书是无效的。所以更新生产证书这个动作几乎是强制要求你同步更新对应的一套描述文件除非你完全走Xcode自动签名让Xcode自己处理。我自己在团队里的处理习惯是能用手动签名就用手动至少在更新证书这种关键操作上不要完全依赖自动签名。不是说自动签名不可靠而是它背后做了很多“隐式操作”出了问题的时候不好定位。手动模式虽然多几步但每一步都能看到状态反而更安心。2.3 怎么判断自己的证书在哪里、长什么样更新证书前先在本地钥匙串里做一次排查。打开“钥匙串访问”Keychain Access左上角选择“登录”然后在右上角搜索“Apple Distribution”或者“Apple Development”就能看到所有和Apple签名相关的证书。每一行对应一个证书展开左侧的小箭头可以看到关联的私钥。正常状态下的证书应该显示“此证书有效”过期或失效的证书会显示红叉或者“此证书已过期”。如果你同时维护多个项目这里可能会看到好几张苹果证书。不要光看名称要双击证书查看详细信息重点是“有效期限”这个字段。凭我经验同一个开发者账号下可能会有开发证书、旧的发布证书、另一个Mac上生成的新证书同时在列表里容易搞混。稳妥的做法是记录下每张证书的序列号和Team ID再去开发者后台核对本机钥匙串里的证书是否与后台记录一致。如果你发现证书对应的私钥不在这把电脑上那么即便你从后台下载新的.cer证书文件双击导入也会提示“证书无效”或者无法用于签名。很多人就是栽在这一步。遇到私钥丢失的情况最直接的办法是用这把Mac重新生成CSR再创建一张新证书同时把旧证书撤掉。下面第三部分我会详细讲这个操作。3. 生产证书更新的完整实操流程3.1 第一步检查钥匙串里的旧证书和私钥更新前一定先备份。我个人的习惯是先打开钥匙串访问找到旧证书右键导出为.p12文件。这一步需要输入密码建议设一个你记得住但不要跟常用密码一样的密码然后保存到安全地方。这个.p12就是“证书私钥”的打包文件后续转移到CI机器或者其他同事电脑时会非常有用。导出的同时检查一下证书是否还关联着有效私钥。展开证书下面如果能看到钥匙图标就说明私钥还在本机。如果只有证书而没有私钥那后面生成CSR时你会遇到大麻烦。具体操作路径钥匙串访问 → 菜单栏“钥匙串访问” → “证书助理” → “从证书颁发机构请求证书”。这一步是生成CSR的必要动作。页面里有两个输入框一个填你的邮箱地址一个填常用名称。邮箱建议填写开发者账号对应的Apple ID邮箱常用名称可以填项目代号或当前日期方便以后区分。下面选项选择“存储到磁盘”点击继续后会保存一个.cerSigningRequest文件这就是上传到后台用的CSR。3.2 第二步在开发者后台创建新证书打开developer.apple.com进入“Certificates, Identifiers Profiles”侧边栏选“Certificates”在Certificates列表右上角点加号。这时会进入创建向导需要选择证书类型。生产证书对应的选项一般是“Apple Distribution”在部分账号界面下会细分为“App Store Connect”和“Ad Hoc”两类。如果只是为了上架App Store选App Store Connect即可如果需要企业内部分发或Ad Hoc测试那就选Ad Hoc。这里注意别选错因为不同类型的证书后续用途差异很大。选好类型后页面会让你上传刚才生成的CSR文件。上传成功后点击继续新证书就创建成功了。后台列表里会出现一行状态为Active的新证书有效期一般显示为三年左右。看到Active之后点击下载会得到一个后缀为.cer的文件。双击这个文件系统会自动导入到钥匙串访问里。导入后在钥匙串里再次搜索Apple Distribution你会看到新旧两张证书共存新证书状态是有效的。这里必须多说一句旧证书过期后你可以选择保留在后台也可以选择删除。如果你的团队有多台Mac和多个证书保留旧证书很容易让Xcode在自动签名时选错所以我个人倾向在确认没有旧版本需要重新签名之后把已过期的旧证书从后台删掉。不过在删除前务必确认这个证书没有正在使用的App版本或推送通道否则会引发一连串问题。拿不准的时候就先不删放到过期列表里也不会影响新证书使用。3.3 第三步同步更新Provisioning Profile证书更新完成后立刻去处理描述文件。在开发者后台侧边栏进入“Profiles”能看到所有已创建的描述文件。找名字里带Distribution或者App Store字样的那一个点进去看“Certificate”列表里是否包含刚才新建的证书。如果描述文件还是关联旧证书那么即使证书更新了签名还是过不了。处理方式很简单在描述文件详情页点“Edit”然后在证书列表中勾选新证书再点保存。保存后系统会重新生成一个包含新证书的描述文件你需要在详情页点“Download”拿到一个.mobileprovision文件。手动签名的项目需要在Xcode里或者直接双击导入这个新描述文件。这里也提一下自动签名的情况。如果你在Xcode里勾选了“Automatically manage signing”那么在后台更新了证书之后可以尝试重启Xcode并等待它自动同步描述文件。大多数情况下Xcode会自动拉取新的描述文件但偶尔会卡住。我的处理办法是在Signing Capabilities页面里先把Team切到“None”再重新选回你的Team强制触发一次刷新。如果还不行就把描述文件相关的缓存清理掉路径在 ~/Library/MobileDevice/Provisioning Profiles 目录下删掉后再让Xcode重新下载。3.4 第四步配置Xcode和项目签名证书和描述文件都准备好之后打开你的项目工程进入“Signing Capabilities”面板。先确认左上角Team选的是你的开发者账号再确认下方签名方式。如果是手动签名把“Provisioning Profile”选成刚才下载的新描述文件如果是自动签名确保“Automatically manage signing”是打勾状态然后等待Xcode右上角出现“All valid”提示。这里有个特别容易踩的坑当你手动配置了新描述文件但Build Settings里的CODE_SIGN_IDENTITY还是指向旧证书名时构建时会报“No certificate matching ...”或者“CodeSign error: certificate identity ... appeared twice”。解决办法是在TARGETS → Build Settings → Code Signing → Code Signing Identity里明确选择“Apple Distribution”或者“iPhone Distribution: 你的团队名”确保它指向钥匙串里新导入的证书。配置完成后先做一次Clean快捷键ShiftCommandK再重新Build。Build成功后用Xcode Organizer或者Transporter上传时系统会重新对App做签名这时使用的就是新证书了。为了保险起见我还会在终端里手动验证一下签名结果。找到编译产物路径比如 ~/Library/Developer/Xcode/DerivedData/你的工程名/Build/Products/Release-iphoneos/你的App名称.app执行codesign -dv 你的App.app 21 | grep Authority正常会输出一串以Apple Distribution开头的证书链信息。只要看到Authorization里包含Apple Distribution或iPhone Distribution并且日期是新的就说明签名确实换过来了。这个方法我在多次上传失败后靠它定位了问题比反复在Xcode里点按钮高效得多。3.5 第五步验证推送、TestFlight和上架链路证书更新签名Build成功以后不要急着把所有东西都打包上传。先把受影响的下游链路全部回归一遍。第一个是TestFlight。如果你们团队依赖TestFlight分发测试包那就要把新Build提交到App Store Connect然后在TestFlight里启用这个构建版本邀请测试人员进行一轮验证。如果之前因为证书过期导致上传失败这个步骤现在就能看到上传成功。第二个是推送。如果你的App使用生产环境的APNs并且你用的还是老式APNs SSL证书那么你要在开发者后台单独检查这张推送证书的有效期。具体入口是Certificates列表里找Apple Push Notification service SSL相关条目。如果推送证书也过期了需要为对应的App ID重新创建一张APNs证书下载后替换到后端推送服务的配置里这个和后端同学要一起配合。如果你们用的是.p8密钥方式那不存在过期问题只需确认密钥没被轮换即可。第三个是Ad Hoc分发如果你有通过Ad Hoc描述文件分发给内部测试机的场景那么别只更新App Store的ProfileAd Hoc对应的Profile也要同步更新并且要把新证书包含进去。因为这个Profile注册了设备UDID如果证书过期设备在安装时会提示无法验证App用户会很直观地看到“无法安装”。这一整套验证做完才算是把“更新生产证书”这件事真正闭环了。我见过太多人只换了后台证书、钥匙串里也导入了结果忽略了Profile或者推送证书第二天测试人员过来抱怨说包装不上、推收不到又要从头查一圈。多花半小时做回归能省下后续一整天的排查时间。4. 更新过程中最常见的坑与排查实录4.1 Xcode提示证书无效但后台明明已经更新这个问题的概率极高我一度以为是Xcode的Bug后来才发现大部分原因是“描述文件缓存不刷新”。Xcode会在本地缓存已经下载过的描述文件即使后台已经重新生成本地也可能还保留旧文件。遇到这种问题先把Xcode关掉然后打开Finder按CommandShiftG进入目录~/Library/MobileDevice/Provisioning Profiles把这个目录下所有文件备份到一个临时文件夹然后全部删除。重新打开Xcode它会自动向开发者后台拉取最新的描述文件。这样处理之后绝大多数“证书明明有效但Xcode就是报无效”的问题都能解决。另一种情况是钥匙串里新旧证书并存导致构建时Xcode匹配到了错误的证书。处理方法是在Build Settings里手动指定Code Signing Identity或者干脆把旧证书从登录钥匙串里删除。不过删除钥匙串里的旧证书前一定确认后台没有旧证书对应的未上架版本否则可能影响线上App的更新时间线。4.2 推送突然全部失败可能是APNs证书而不是签名证书我在文章开头就提到过这个坑。有次客户说App推送全挂了我们第一反应是检查生产证书更新完签名后发现推送还是不行。后台检查才知道APNs的Sandbox与Production SSL证书也在申请后的第364天到期。注意这个证书路径跟代码签名是完全独立的很多后台管理系统要求同时配置两个证书一个是APNs证书文件一个是私钥。如果证书过期推送服务连接APNs时就会报“Invalid token”或“SSL connection error”。如果你用的是传统.cer方式的APNs证书更新操作是去后台Certificates里新建一张“Apple Push Notification service SSL (Sandbox Production)”证书下载后替换到推送服务商的控制台里。如果是.p8密钥方式则不存在过期问题但Apple建议定期轮换轮换时要同时替换后台配置。4.3 换了新证书CI机器上还是签不了名很多开发团队都有自己的CI机器比如用Jenkins、GitHub Actions或者自建的打包服务器。本地电脑更新了证书之后CI机器上如果还是旧证书打包自然失败。解决办法是把新证书的.p12导出文件包含私钥和安全密码都配置到CI对应的钥匙串里同时把新的.mobileprovision描述文件也同步过去。这里有个安全细节CI机器上配置钥匙串时一定不要用系统默认钥匙串建议单独创建一个构建专用的钥匙串。例如在macOS上执行security create-keychain -p 密码 build.keychain security import 证书.p12 -k build.keychain -P 私钥密码 -T /usr/bin/codesign这样既能让codesign找到证书又不会污染系统主钥匙串。配置完成后记得在打包脚本里明确指定lock和unlock的操作避免构建过程中钥匙串被锁住。4.4 自动签名看似省事但多人协作时容易互相踩踏当团队里多个成员都勾选了“Automatically manage signing”Xcode偶尔会在后台创建新的证书和描述文件导致整个团队使用的证书漂移。最典型的症状是今天你本地打包正常明天另一个同事一拉代码签名报错因为Xcode给团队又自动生成了一个新证书。这时候后台会出现好几张重复的Distribution证书每张的状态都是Active。我的建议是团队里指定一个人作为证书管理员统一在后台维护证书和描述文件。其他成员的Xcode工程尽量设置为手动签名使用同一个描述文件。同时证书管理员要定期检查后台有没有“多出来”的证书如果发现重复选择性地删除旧的、还在Active状态的证书避免后续混淆。当然删除前要确认没有正在使用中的Profile关联着它。4.5 钥匙串导入新证书后提示“证书不受信任”这看起来吓人但多半只是中间证书链缺失。Apple的代码签名证书依赖Apple WWDR (Worldwide Developer Relations)中间证书。如果你在钥匙串里看不到WWDR证书可以打开后台Certificates页面下载最新的Worldwide Developer Relations中间证书并导入。导入完成后之前的红色提示就会消失。如果你发现导入.cer后钥匙串里证书一直处于“此证书已被撤销”状态那可能是Apple后台确实把它标记为Revoked。这种情况不要想本地能不能绕过只能老老实实重新创建一张新证书。撤销状态意味着这张证书无论如何都不能再用于签名继续修钥匙串只是浪费时间。5. 别等过期证书与描述文件的长期维护建议5.1 把证书到期日写进团队日历证书有效期一般是三年看起来很久但三年时间足够让团队人员变动一轮。最稳妥的办法是在创建证书的那一天就在团队日历上标记“证书到期前60天”和“证书到期前30天”两轮提醒。我甚至建议在CI脚本里加一个检查逻辑在证书剩余有效期不足30天时自动在构建日志里打印警告这样即使日历提醒被淹没在会议通知里构建环节也能帮你兜底。具体的检查命令也很简单。如果你把证书文件导出为.cer并转换为PEM格式可以执行openssl x509 -in certificate.pem -noout -enddate拿到日期后跟当前时间做比较就能知道剩余天数。这个脚本可以塞进每周的定时任务里效果非常好。5.2 重要证书统一走fastlane match或集中管理如果你所在的团队有多个项目强烈建议用fastlane match统一管理证书和描述文件。match会把证书和Profile加密后放进一个私有仓库团队所有成员统一通过它安装同一套签名文件签发时还会自动处理过期和替换。这种方式能够彻底解决“私钥只在你电脑上”“同事电脑签不了名”“证书漂移”这类问题。当然引入match也有学习成本至少Architecture和团队协作方式要有一个明确的调整。如果团队规模比较小也可以退而求其次把.p12和.mobileprovision放到公司内部的共享网盘里设置好密码和权限并在文档里写明更新流程。但说实话只要超过三个人开发同一个iOS项目match的收益就非常明显值得投入半天时间做迁移。5.3 私钥备份与交接要趁早证书更新这种事最怕遇到“上一任维护者离职了私钥没留下”。私钥丢失后老证书即使没过期也只能作废必须重新创建新证书并把所有Profile重新关联一遍。所以我的经验是每次导出.p12的时候把密码用密码管理器同步记录不要把密码写在邮件或聊天记录里。备份文件最好放在两个不同位置比如公司内部网盘加一个加密U盘。团队交接证书管理权的时候要让接收方当场验证一下能打开钥匙串看到私钥、能登录后台看到证书和Profile、能成功Build一次App。验完这三样交接才算完成。不然下一个人到用的时候才发现有问题又得从头排查时间成本浪费得毫无意义。5.4 关注苹果的证书策略变动苹果偶尔会调整证书和描述文件的类型、有效期以及管理入口。比如近几年出现的Apple Distribution证书以及把部分操作迁移到App Store Connect后台都让很多老教程变得过时。我的建议是每半年去Apple Developer后台把证书、描述文件、密钥三个模块都大致过一遍重点看有没有新增的命名差异或者旧入口的变化。这不需要多高深的技术背景但能防止你在关键时刻拿着过时的截图找不到按钮。最后再分享一个我自己的操作习惯我在处理生产证书过期这件事上从来没有只把它当成一个“补丁式”任务而是借机把整个发布链路的关键文件全部体检一遍。具体来说我会列一个清单生产证书是否有效、APNs推送证书是否有效、所有Distribution描述文件是否有效、CI机器上的.p12是否是最新、团队里每台开发机是否能正常签名。这五件事平时没人会主动想起但在“证书过期”这个时间节点上顺手做一遍特别方便。有一次我就是因为在更新生产证书时顺手把推送证书也换了结果避免了项目上线前一周推送突然挂掉的悲剧。同事还以为是运气好其实只是多花了半小时做例行检查。证书过期这件事本质上不是技术难题而是一个流程和管理问题。把流程理顺了证书过期的处理时间可以控制在半小时以内完全不会打乱发布计划。