📚 课程目录第2章 Keystore详解

Keystore 详解：密钥库格式、创建与导出、查看证书信息、别名与密码管理

开篇先聊聊 Keystore 的本质。说白了，它就是一个加密的保险柜，专门存放 Android 签名用的私钥和证书链。我刚开始接触签名时，总觉得它就是一堆文件操作，后来踩过坑才明白——Keystore 格式、密码策略、别名管理，每一项都直接影响你的发布效率和安全性。

密钥库格式：JKS vs PKCS12 vs BKS

你打开 Android Studio 生成签名时，默认会创建 .jks 文件。JKS 是 Java 原生的，但有点老；PKCS12（.p12 或 .pfx）是更通用的国际标准；BKS 是 Bouncy Castle 实现，常用于旧版 Android。我个人的建议是：新项目一律用 PKCS12。为什么？

格式	后缀	特点	推荐场景
JKS	.jks	Java 专有，只能存私钥和证书，不支持加密私钥单独导出	老项目兼容
PKCS12	.p12 / .pfx	跨平台、支持证书链和扩展属性，密钥容器更安全	新项目首选
BKS	.bks	Android 2.x 时代常用，API 19 以后逐渐被 PKCS12 取代	历史遗留

关键结论：Android Studio 3.0 之后默认使用 PKCS12，但在它生成 .jks 时其实底层也封装了 PKCS12。我个人习惯是命令行手动创建 .p12，对格式有控制权。

创建与导出：手把手敲 keytool

创建 Keystore 的核心命令是 keytool -genkeypair。举个典型例子：

keytool -genkeypair -v \
  -keyalg RSA \
  -keysize 2048 \
  -validity 10000 \
  -keystore release.keystore \
  -storetype pkcs12 \
  -alias my_app_key \
  -storepass 123456 \
  -keypass 123456

参数说明：

-keyalg RSA：RSA 算法是 Android 签名主流
-keysize 2048：2019 年后 Google Play 要求至少 2048 位
-validity 10000：有效期约 27 年，覆盖应用整个生命周期
-storetype pkcs12：明确指定 PKCS12 格式
-alias：这条密钥在保险柜中的「钥匙编号」

我曾经犯过的错：某次给客户导出签名文件，直接用 Android Studio 默认生成的 .jks 交给了对方团队。结果他们用的 CI 系统只认 .p12，最后不得不重新生成并更换应用签名。所以 如果有跨平台需求，请一开始就输出 PKCS12 格式。

导出证书文件（用于上架商店或分发给第三方）：

keytool -exportcert -v \
  -alias my_app_key \
  -keystore release.keystore \
  -storepass 123456 \
  -file cert.cer

查看证书信息

拿到一个 Keystore 文件后，如何确认里面的内容？用 -list -v 参数查看完整信息：

keytool -list -v -keystore release.keystore -storepass 123456

你会看到类似这样的输出：

别名: my_app_key
创建日期: 2024-01-15
条目类型: PrivateKeyEntry
证书链长度: 1
证书[1]:
所有者: CN=Your Name, OU=Dev, O=Company, L=City, ST=State, C=CN
签发者: CN=Your Name, OU=Dev, O=Company, L=City, ST=State, C=CN
序列号: 6a7b8c9d
有效期开始: 2024-01-15 10:00:00
有效期结束: 2051-06-03 10:00:00
证书指纹:
         SHA1: 1A:2B:3C:4D:5E:6F:70:89:9A:BC:DE:F0:12:34:56:78:90:AB:CD:EF
         SHA256: 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF

重点检查三个地方：

别名是否存在——有时候你输错名字，gradle 构建时找不到密钥直接报错
证书有效期——如果失效，应用将无法更新
SHA256 指纹——上架 Google Play 或微信开放平台时经常需要提供

别名与密码管理

别名的作用很简单：在同一个 Keystore 里区分不同密钥。但很多人会忽略它的命名规范。我见过团队用 key0、key1 这种毫无意义的别名，结果项目交接时根本不知道哪条是正式签名。

推荐命名规则：{项目代号}_{用途}_{版本}，例如 myapp_release_v2。这样即使 Keystore 里有三四条历史密钥，也能一眼识别。

密码管理是另一个痛点。-storepass 是保险柜密码，-keypass 是钥匙密码。如果两者不同，构建脚本就需要分别配置。我个人习惯让它们保持一致，但不能把密码硬编码在 gradle.properties 中并提交到 git。你可以用环境变量：

// gradle.properties
MYAPP_RELEASE_STORE_PASSWORD=System.getenv("STORE_PASS")
MYAPP_RELEASE_KEY_PASSWORD=System.getenv("KEY_PASS")

或者用 Android Studio 的 Encrypted keystore 功能（在安全设置里启用）。

SVG：Keystore 内部结构一览

避坑指南

最后总结几条我亲身踩过的「签名炸药」：

永远不要丢失 Keystore 文件——一旦丢失，已有用户的应用将无法升级。可以考虑备份到离线加密介质或 HSM。
同一个应用不允许混用多个 Keystore——不同 Keystore 生成的签名指纹不同，Android 系统会认为是两个应用。
密码不要用简单的数字串——我见过有人设 111111，结果被内部同事乱用签名。建议用至少 16 位包含大小写字母与特殊字符的密码。
CI/CD 环境下慎用明文密码——使用 Jenkins 的 Credentials Binding 插件或 GitHub Actions 的 Secrets。

一个小技巧：如果你需要将 .jks 迁移到 .p12 格式，可以用 keytool -importkeystore -srckeystore old.jks -destkeystore new.p12 -deststoretype pkcs12。无需重新生成签名。

掌握了这些，你就能从容管理签名文件，不会再被「密钥库格式不对」「密码错误」「别名找不到」这种低级问题卡住构建流程。记清楚了——格式选 PKCS12，别名起得有意义，密码藏好别提交 git，后面才敢放心去配置 AGP。