鸿蒙 OS 的签名密钥机制，我终于整明白了！

在做移动应用开发时，不管是 Android 还是 iOS，我们都绕不开“签名”这件事。最近我们项目在筹备适配 HarmonyOS NEXT（鸿蒙 Next） 的 SDK，也顺势把鸿蒙的签名机制研究了一遍。这篇文章来分享下。

简单来说，签名的目的是确保应用的来源可信、内容完整、平台可识别。我们开发的应用，最终都要交给系统安装，那系统当然得确认一下：这个包是“你”发的、这包在传输过程中没被篡改、它是我允许安装的对象。这就要靠数字签名。

说到底，数字签名就是：

用私钥对应用包里的内容摘要加密，生成一个签名块，塞进包里。
系统在安装时用你当初的公钥解密它，校验签名是否匹配。如果一切对得上，才会放行。

我们先复习下 Android 和 iOS 的签名流程，再看看鸿蒙的做法是怎么“融合创新”的。

Android 签名机制回顾

搞过 Android 的同学都知道，签名这套流程绕不开 Keystore 文件（.jks 或 .keystore）。它是个密钥库，里面有你生成的一对公私钥。

生成方法嘛，Android Studio 自带的工具或者命令行 keytool 都能搞。你得设置密码、别名、组织机构之类的。

签名流程一般是：

  1. 用 apksigner 或 jarsigner 对 APK 进行签名；

  2. 安装时，系统会从 APK 中提取签名块；

  3. 用嵌入的 公钥 验签；

  4. 检查包的内容有没有被改动。

重点是——升级包必须用相同密钥签名！
否则就会被系统拦下来，提示你“签名不一致，不能覆盖安装”。

后来 Google 推出了 App Signing by Google Play 服务。你可以只上传未签名的 APK 或用上传密钥签过的 APK，真正的签名工作交给 Google，它用你存的密钥进行最终签名和分发。

iOS 签名机制回顾

iOS 的签名体系就偏“官僚”一点，全靠 Apple 的一套证书系统撑着。

要发布一个 iOS 应用，你得准备这三样东西：

  • .cer：Apple 颁发的开发者证书，内含你的公钥和身份；

  • .p12：你本地生成的私钥文件，用于签名；

  • .mobileprovision：描述文件，绑定了证书、App ID、设备 ID 等。

整个签名过程和证书链校验基本都在 Apple 的 Xcode 工具和 Apple 服务端完成。只要你照着官方流程来，一般不会出啥问题。

鸿蒙 Next：签名机制融合 Android + iOS 的思路

我们项目要接入鸿蒙 Next，第一件事就是：搞清楚签名密钥这一套怎么玩。研究之后发现，鸿蒙的机制融合了 Android 的密钥库和 iOS 的证书申请体系，整体看起来像是“Android 的私钥管理 + iOS 的证书申请 + 描述文件配置”。

一共涉及 4 个关键文件：

签名流程详解：一步步把包“合法化”

1. 本地生成 .p12 文件 —— 创建密钥对

你用 DevEco Studio 在本地生成 .p12，里面有一对非对称密钥对（公钥 + 私钥）。

  • 私钥以后用来签名 HAP（HarmonyOS 应用包）；

  • 公钥则被嵌入到 .csr 文件里，发给华为去申请证书。

2. 生成 .csr 文件 —— 证书请求

.csr 文件是你发给华为的“申请信”，它里面包含了：

  • 你的身份信息（开发者名、组织名等）；

  • 你刚刚生成的公钥。

这一点就跟 iOS 的证书申请很像。

3. 提交 .csr 到 AppGallery Connect，申请 .cer 数字证书

这个时候，轮到华为出场了。它会用自己的 CA 私钥 给你签发一张开发证书（.cer 文件）。这个证书里包含：

  • 你的身份信息；

  • 你的公钥；

  • 华为 CA 的签名，确保这张证书是“正宗华为出品”。

通过解析 .csr 的公钥和 .cer 中的开发证书公钥可以发现是同一个。

这样就构建了一条完整的信任链。

4. 构建证书链，验证签名合法性

签了 .cer 后，你的 .p12（公私钥对）就算是“被认证过的开发者密钥”了。系统在安装你签名过的 HAP 包时，会验证：

  • 你的包是不是用这个私钥签的；

  • 这个私钥有没有经过华为签发的证书认证；

  • 这张证书是不是华为签的。

说白了：一层层往上追溯，直到能从信任的 CA 根证书“闭环”，才算合法。

5. 最后一步，生成 .p7b 描述文件 —— 权限、包名、设备绑定

这个 .p7b 文件相当于一个“出入证”，告诉系统这个包：

  • 来自哪个包名；

  • 拥有哪些权限；

  • 是调试包还是发布包；

  • 如果是调试包，哪些设备可以安装；

  • 对应的证书有哪些。

它是以 PKCS#7 格式 打包的，不能少，系统验证的时候会用上。

写在最后

鸿蒙的签名机制说起来复杂，但其实拆开来看就是融合了我们熟悉的 Android 和 iOS 的思路 —— 本地生成密钥，上传公钥申请证书，拿到证书签名包，加上一个描述文件来“做身份认证和权限声明”。

整个流程稍微绕一点，但掌握之后就能把签名流程自动化集成到你的打包流程里。我们现在项目中已经把签名密钥的管理、HAP 签名打包全自动串起来了，做成了 CI/CD 中的一环。

如果你也要做鸿蒙适配，早点熟悉这套流程，绝对事半功倍！