在做移动应用开发时，不管是 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 个关键文件： |文件名|用途|格式| |---|---|---| |Keystore|储存公私钥|`.p12`| |CSR（证书请求）|提交给华为申请证书|`.csr`| |数字证书|华为签发的开发/发布证书|`.cer`| |描述文件 Profile|应用权限、设备、证书绑定等信息|`.p7b`| --- ## 签名流程详解：一步步把包“合法化” ### 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 中的一环。 如果你也要做鸿蒙适配，早点熟悉这套流程，绝对事半功倍！