android签名证书,提取安卓系统签名证书

Android签名证书(.keystore)生成指南

注意⚠️，这里的前提是已经安装了JDK 环境。

/usr/libexec/java_home -V

然后我们先 cd 到这个路径，因为要把证书生成在这个目录下：

cd /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home

sudo keytool -genkey -alias 自定义名.keystore -keyalg RSA -sigalg SHA1WithRSA -validity 20000 -keysize 1024 -keystore 自定义名.keystore -v

之后根据提示输入密码和一些信息。

最后提示我们需要做一个迁移到 pkcs12 格式的操作，那么就照做。

sudo keytool -importkeystore -srckeystore animaluni.keystore -destkeystore animaluni.keystore -deststoretype pkcs12

可能会有权限的问题，所以都别忘了加 sudo 。

这时打开我们的 jdk 目录，就可以看到生成的证书?了。真正用的肯定是不带 .old 的版本。

keytool -list -v -keystore [所在路径/]xxx.keystore

相关问答

Q1: Android 签名证书过期怎么办？

Android中目前三种签名，签名过期的问题，在 Android 9.0 上新支持的 V3 签名，已经有解决的方案了。另外：

V1 签名：遵基于 JAR 签名。 单独验证 APK 压缩包中的文件。

V2 签名：APK 签名方案 V2，在 Android 7.0 引入。是针对 APK 文件的验证，将签名信息写入签名块中，增强了安全性和验证效率。

V3 签名：APK 签名方案 V3，在 Android 9.0 引入。在签名块中又增加了新块（attr），由更小的 level 块，以链表的形式存储多个证书。

在 V3 方案中，最旧的证书为新块链表的根节点，以此对新证书签名，确保新证书正确有效。

参考：  App 签名过期或泄露怎么办？

Q2: 一文弄懂关于证书，签名，ssl，android包签名机制。

所有的概念都基于一个非常重要的基础：

rsa 非对称加密算法 ：

先感受下几个概念

PKI。

PKI是公钥基础设施（Public Key Infrastructure) 包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。

我们关注就俩东西： PKCS 证书机构CA 。前者是定义加密算法，签名，证书相关的各种事情采用的协议。后者可以为我们颁发权威的证书。

PKCS ：

PKCS（The Public-Key Cryptography Standards ）是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。RSA算法可以做加密、解密、签名、验证，还有RSA的密钥对存储。这些都需要标准来规范，如何输入，如何输出，如何存储等。

PKCS。全称是公钥密码学标准， 目前共发布过 15 个标准，这些标准都是协议。总结一下 就是对加密算法，签名，证书协议的描述。下面列举一些常用的协议，这些协议在本文都会对应上。

这些协议具体的实现就体现在openssl等工具中， 以及jdk工具keytool jdk java第三方库bouncycastle。

比如用openssl 如何生成公/私钥(PKCS#1)、签名(PKCS#1 )、签名请求文件（KCS#10）、 带口令的私钥（PKCS#8）。 含私钥的证书（PKCS#12）、证书库（PKCS#12）

其中涉及到算法的基础协议PKCS#1等，由于涉及到密码学原理所以我们并不需要深究它，只要知道怎么做就可以了。

现实中我们要解决这样一种情况:

客户端和服务器之间的数据要进行加密。需要两个达成同一个对称秘钥加密才行，那么这个秘钥如何生成，并在两边都能拿到，并保证传输过程中不被泄露。 这就用到非对称加密了。 后续的传输，就能用这个 对称秘钥来加密和解密了。

还有这样一个问题：

就是客户端如何判断服务端是否是合法的服务端。这就需要服务端有个id来证明它，而这个id 就是证书，而且必须是权威机构颁发的才能算是合法的。

因为客户端即浏览器，认定证书合法的规则必须通过第三方来确认 即ca颁发的证书。否则就我可能进了一个假网站。

而这两个问题 都是ssl协议要解决的内容。

所以ssl协议做了两件事情，一是验证身份，二是协商对称秘钥，并安全的传输。 而实现这个过程的关键数据模型就是证书， 通过证书中的ca对证书的签名，实现了身份验证，通过证书中的公钥，实现对对称秘钥加密，从而实现数据保密。 其实还顺手做了一件事情就是通过解密签名比对hash，保证了数据完整性。

明白ssl协议 首先明白几个重要的概念：

证书： 顾名思义就是提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书， 就是可以认定是合法身份的。客户端不需要证书。 证书是用来验证服务端的。

一般的证书都是x509格式证书，这是一种标准的证书，可以和其他证书类型互相转换。完整来说证书包含，证书的内容，包括 版本号， 证书序列号， hash算法， 发行者名称，有效期， 公钥算法，公钥，签名（证书原文以及原文hash一起签名）而这个内容以及格式 都是标准化的，即x509格式 是一种标准的格式。

签名: 就用私钥对一段数据进行加密，得到的密文。 这一段数据在证书的应用上就是 对证书原文+原文hash进行签名。

谁签的名，就是用谁的私钥进行加密。就像身份证一样， 合法的身份证我们都依据是政府签的，才不是假证， 那就是浏览器会有政府的公钥，通过校验（解密）签名，如果能够解密，就可以确定这个就是政府的签名。就对了。

hash算法 ：对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。比如，MD5和SHA-1及其大量的变体。 hash算法具有不可逆性，无法从摘要中恢复出任何的原始消息。长度总是固定的。MD5算法摘要的消息有128个比特位，SHA-1算法摘要的消息最终有160比特位的输出。

ca机构： 权威证书颁发机构，浏览器存有ca的公钥，浏览器以此公钥来验证服务端证书的合法性。

证书的获取： 生成证书申请文件.csr（涉及到PKCS#10定义的规范）后向ca机构申请。 或者自己直接通过生成私钥就可以一步到位生成自签名证书。 自签名证书就是用自己的私钥来签名证书。

那么为了体现到 证书身份认证、数据完整、保密性三大特性 ，证书的简化模型可以认为包含以下两个要素：服务器公钥，ca的签名（被ca私钥加密过的证书原文+原文hash），

身份认证：

浏览器存有ca公钥，用ca公钥解密网站发给你的证书中的签名。如果能解密，说明该证书由ca颁发，证书合法。 否则浏览器就会报警告，问你是否信任这个证书，也就是这个网站。这时候的证书可以是任何人签发的，可以自己签发的。 但是中间人攻击。 完全伪造新的证书， 这就没有办法了。 所以还是信任证书的时候要谨慎。

数据完整：

如果你信任该证书的话，这时候就会用证书中的公钥去解密签名，如果是ca签发的证书，那么之前就已经通过ca的公钥去解密签名了。 然后得到证书hash，然后在浏览器重新对证书做hash，两者比对一致的话，说明证书数据没有被篡改。

保密性：

使用证书的公钥对对称秘钥加密保证传输安全，对称秘钥生成后，后续的传输会通过对称秘钥来在服务端和客户端的加解密。

那么ssl协议的具体过程就是：

4.网站接收浏览器发来的数据之后 使用自己的私钥校验签名，并对原文进行hash 与解密出的hash 做比对检查完整性。然后发送编码改变通知，服务器握手结束通知（所有内容做hash ）。 发送给客户端校验。

5 客户端校验，校验成功后，之后就用 对称秘钥进行通信了。

总共的过程是 c-s-c- s-c 四次握手。

四次握手简单来说分别是：

1.请求获取证书

2.服务端返回证书，客户端验证了证书的合法性和完整性，同时生成了对称秘钥。

3.客户端把加密的 对称秘钥发给服务器。服务器检查真实性和完整性。

4.服务端返回握手结束通知，客户端再检查一次真实性和完整性。

前两次握手是明文， 后两次握手是密文。 所以都要检查身份真实性和数据完整性。

ca的作用：

ca起到一个权威中间人的角色，如果脱离了ca， 那么证书还是证书，还能加密，保证数据完整性。 但是无法应用在客户端去认定服务器身份合法这个场景下。

  

下面就详细说下 脱离了ca签发的证书的应用：

  

自签名证书：

证书如果没有权威机构的签名，就是没有权威机构给你签发身份证。 那么这时候身份认证的场景变了。

这时候的认证场景就变成了，不再是某个官方权威说了算，而是假设第一次碰到这个证书，会认为，这个证书与之捆绑的实体之间是合法的并做记录。如果当这个实体下次捆绑了另一个证书，那么就是非法的。

这种情况常用于android中安装和校验app的时候，会先假设第一次安装的是合法的应用，认定这个app证书中的公钥是合法的公钥。然后通过自签名的证书，校验签名，就能实现后续安装是否合法以及完整性。

android中的如何对app进行身份认定和不被篡改：

android系统在安装app时候会进行校验applicationId，applicationId 不同会认定为不同应用。相同应用，第二次安装会校验证书是否和之前app的证书相同，如果相同则两个包很可能来自同一个身份。 如果证书不同，也就是该包被另一个身份用自己的私钥重新签名过，就会拒绝安装。 然后通过公钥来解密签名，如果能解密，说明身份是ok的。否则拒绝安装。比对解密签名后的hash 与apk包内的cert.sf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。

android在提交应用商店的问题：

应用商店也会校验 后续的上传和第一次上传时的证书，以及类似上述的后续的一系列校验。防止合法的开发者平台被盗后，上传非法应用。

android在接入第三方sdk的问题：

接入第三方sdk 会提交applicationId 和 sha1 值。 这个sha1值就是对 证书原文的签名后的sha1，也就是证书指纹。这个证书是证书库里最初的那个证书（x509格式），而不是对apk签名后生成的证书(PKCS#7)。一般的证书签名的主体是证书原文本身，而对apk签名还额外会对apk所有文件生成的hash值文件（cert.sf）进行一次签名。

第三方平台会记录 applicationId 与sha1 的对应关系。 当有假冒app试图接入时候，由于会对app内的PKCS#7证书转换为原始的x509格式证书，重新生成sha1值，与用户提交sha1 比对， 如果相同则说明证书很可能是ok的。 因为sha1就是证书的指纹。 之后就会通过证书中的公钥来校验签名，从而最终确认身份合法性以及信息完整性。

第三方平台之所以需要用户去提交证书指纹sha1值，多了这一步，就意味着你的证书是可以更换的，一旦更换了证书，就必须提交新的指纹给我，然后我来做匹配。而应用商店没有这个功能， 一旦你的证书的私钥丢了， 那就必须重新建一个新的app。

总结来看证书的身份认定机制：

在ssl协议下，这种场景是 浏览器用于认定合法的服务器身份。 在自签名证书下，需要用户选择是否信任该证书。

在android app采用自签名证书的场景下， 证书起到了 假设第一次的证书合法，公钥合法，后续如果证书不一致或不能够完成签名校验，就是非法。

证书库：

证书库应该满足PKCS#12协议。 但是jdk提供了制作证书的工具keytool 可以生成keystore类型的证书库，后缀为jks。 keystore pk12可以通过keytool命令互相转换。

证书库是个证书的容器， 可以用来创建数字证书。 在keystore证书库中，所有的数字证书是以一条一条(采用别名alias区别)的形式存入证书库的。证书库中的证书格式为pk12，即包含私钥。 如果导出证书的话， 可以导出为x509不包含私钥的格式 或者pk12包含私钥的证书。 也可以也可以用-import参数加一个证书或证书链到信任证书。

android中一般都采用读取证书库的方式，通过证书库来创建一个证书，通过alias来区分。 所以在签名的时候，一个alias是一个证书，不同的alias是不同的证书，不要搞错了。

几个关系：

证书和非对称加密算法的关系：

证书代表一个身份的主体，包含了非对称秘钥体系中的公钥，以及用私钥对证书签名。这种组织结构，把非对称加密算法从加密的功能，拓宽到了用于身份认证，信息完整性上。这体现在了证书的作用。 本质还是利用了非对称加密算法的特性。

ssl协议和证书的关系。

因为证书解决了客户端对服务器的身份认证（自签名证书除外），同时也解决了加密，和信息完整性，所以ssl协议基于证书来实现。

Q3: Android签名机制之签名文件和数字证书的作用

Android签名机制目的是确保app的可靠通信，其一，要确定消息的来源确实是其申明

的那个人；其二，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以

发觉出来。

所谓数字签名，就是为了解决这两个问题而产生的，它是对非对称加密技术与数字摘要

技术的一个具体的应用。

对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。

如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的

消息外，还要加上另外一段消息。这段消息通过如下两步生成：

1）对要发送的原始消息提取消息摘要；

2）对提取的信息摘要用自己的私钥加密。

通过这两步得出的消息，就是所谓的原始信息的数字签名。

而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，

二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：

1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致；

2）对附加上的那段数字签名，使用预先得到的公钥解密；

3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者

发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，

消息不可信。

通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传

送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始

的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息

的摘要，也不能伪造出数字签名。

那么数字签名呢？

综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字

串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。

不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者

必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好

人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具

备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解

决了。

所谓数字证书，一般包含以下一些内容：

证书的发布机构（Issuer）

证书的有效期（Validity）

消息发送方的公钥

证书所有者（Subject）

数字签名所使用的算法

数字签名

可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的

公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便

便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的

一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂

前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个

证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的

安全发放问题。

综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：

引用链接：