上个月帮朋友处理 App 备案，后台要填 Bundle ID、公钥证书和 SHA-1 签名。他手边只有一个 p12，Mac 又不在身边，翻遍了 Windows 上的文件夹也没找到 SHA1 在哪。说实话，很多人第一反应是去 App Store Connect 里找，其实备案要的 SHA1 在证书里。把这些文件拖进 Appuploader 的文件查看，几项信息都能直接读出来。这篇就讲 App 备案 SHA1 怎么查，以及 p12、ipa、mobileprovision 这三种文件分别能核对什么。

第一步：先确认备案要填哪几项

iOS 这边，备案系统一般要填四样：Bundle ID、公钥证书、SHA-1 签名、服务器域名。Android 那边填的是包名、公钥证书、MD5 指纹和服务器域名，两边的字段不一样，别拿错。

两个容易混的点先记一下：SHA-1 和 SHA-256 是两串不同的指纹，备案要的是 SHA-1；Bundle ID 是 App 的包名，Team ID 是开发者账号的团队编号，也不是一回事嘛。填之前先看清楚输入框旁边写的是哪个。如果 App 已经上架，Bundle ID 也能在 App Store Connect 里查到。备案系统里的公钥，指的是证书的公钥，不是私钥，别把两个搞反。

备案要的是「这个 App 的签名信息」，不是随便一张证书的信息。 证书拿错，后面全白填。

第二步：p12 里看 SHA1 和公钥

把 p12 拖进 Appuploader 的文件查看，能看到名称、Team ID、有效期、序列号、SHA1、SHA256、公钥，以及私钥和证书是否匹配。备案要的公钥证书和 SHA-1 签名，直接从这里复制就行；需要 PEM 格式的话，也能把公钥或私钥导出来。SHA1 是一串 40 位十六进制，复制完整，别少一位。

这里有两个坑。第一，p12 要用实际给这个 App 签名的那张证书，开发证书和发布证书的 SHA1 不一样，拿错了备案信息和安装包对不上。第二，看私钥匹配那一项，显示不匹配的话，这个 p12 本身就有问题，先别急着填。

p12 里带着私钥，别随手传到不明网站去解析。用本地工具打开、看完就收好，比在线转换稳当。

还没有 p12 的话，先在客户端里创建开发或发布证书，下载下来再按上面的步骤看。证书创建和文件查看是两件事，别在证书列表里找 SHA1，入口不在一处呢。p12 设了密码的话，打开时先准备密码，别到时候卡在这一步。

第三步：ipa 里核对实际签名证书

手上只有安装包、没有证书文件的时候，把 ipa 拖进文件查看。它能读出这个包实际使用的签名证书、内嵌的描述文件，以及描述文件里包含的设备 UDID。ipa 里的 UDID 清单是描述文件带进来的，不是 App 自己写的。

这一步适合做交叉验证。比如你从 p12 里抄了 SHA1，准备去备案，先拿 ipa 看一眼：这个包签名用的到底是不是这张证书？如果 ipa 里的证书和 p12 对不上，说明打包时用错了证书，备案填了也白搭。有些外包只给 ipa，不给 p12；这种只能先从 ipa 确认签名证书和描述文件，SHA1、公钥还得找交付方要 p12。

另外，ipa 里的描述文件类型也值得看一眼。开发、Ad Hoc、App Store 三种描述文件对应不同的分发方式，装到测试机上失败，很多时候就是类型不对，或者设备 UDID 没进清单。

第四步：mobileprovision 看 Bundle ID 和设备

单独的 mobileprovision 也能拖进去看，内容是 Bundle ID、签名证书、设备清单和有效期。描述文件有有效期，临近到期就提前重建，别等装不上才想起来。排查签名问题时，这一步比猜快得多。

几个常见现象可以对着看：安装提示描述文件无效，先看有效期过没过；提示设备不在描述文件里，去看设备清单有没有这台机器的 UDID；打包报证书不匹配，核对描述文件里引用的证书和打包用的证书是不是同一张。找到是哪一项不对，再回去重新生成，别在打包参数上反复试（别问我怎么知道的）。

Bundle ID 也要和备案系统里填的一致，大小写都算。描述文件换过之后，Bundle ID 没变，但证书可能换了，备案信息要跟着核对一遍。

三个文件的关系可以这样理解：p12 是证书和私钥，mobileprovision 是描述文件，ipa 是打包后的成品。备案要的签名信息来自证书，描述文件决定这个包能装到哪些设备，ipa 则把两者绑在一起。手上有什么文件，就看哪一层。

第五步：把信息填进备案系统

把 Bundle ID、SHA-1、公钥挨个复制过去，服务器域名单独填。复制的时候留意有没有多带空格或换行，有些后台对格式卡得比较死，粘进去看着一样，提交却报错。

填完干脆自己核对一遍：SHA1 是不是 40 位十六进制、公钥是不是完整的 PEM 内容、Bundle ID 和 ipa 里的是不是同一个。备案审核要时间，填错了再改，来回折腾的是自己。不同省份、不同云厂商的备案页面字段略有差异，以页面提示为准。填完记得保存一份截图或文本记录，下次换人接手不用重查。

第六步：和 Mac 上的命令比一比

印象里，Mac 上查这些信息也有现成的路子： security 可以列签名身份， openssl 能解析 p12， codesign 能看 App 的签名信息，钥匙串访问和 Xcode 的 Devices 窗口也能翻。命令行的好处是能写进脚本，批量核对多个包；代价是要记参数，遇到 p12 密码、证书链这些细节，输出看起来有点费劲。命令行的输出字段多，第一次看容易漏，可以先用图形界面看一遍，再对照命令。

Appuploader 站的是图形界面这一侧：把文件拖进去，字段按名字列出来，复制按钮就在旁边，Windows、Linux、macOS 都能用。反正它不是要替代命令行，日常查一两个包、给备案凑材料，图形界面更省事；要做自动化，还是脚本合适。

把这些信息留一份

顺序可以记一下：先确认给 App 签名的是哪张证书，用 p12 看 SHA1 和公钥；再拿 ipa 核对实际签名和描述文件；单独的 mobileprovision 用来看 Bundle ID、设备和有效期；信息对上之后，再填备案系统。

App 备案 SHA1 这件事，工具只是把信息读出来，填之前确认证书对不对，才是关键。建议每发一个版本，把证书信息、描述文件有效期和 Bundle ID 记一份，下次备案或者换人接手，大概不用再从头翻吧。