keytool加密算法

① 如何给Android应用程序签名

Android系统要求所有的程序经过数字签名才能安装，如果没有可用的数字签名，系统将不许安装运行此程序。不管是模拟器还是真实手机。因此，在设备或者是模拟器上运行调试程序之前，必须为应用程序设置数字签名。·所有的程序都必须签名，没有被签名的程序，系统将不能安装。
·可使用自签署证书签署应用程序，无须授权凭证。
·系统仅仅会在安装的时候测试签名证书的有效期，如果应用程序的签名是在安装之后才到期，那么应用程序仍然可以正常启用。
·可以使用标准工具-Keytool and Jarsigner-生成密钥，来签名应用程序的.apk文件。
Android SDK 工具可以在调试时给应用程序签名。ADT插件和Ant编译工具都提供了两种签名模式-debug模式和release模式
·debug模式下，编译工具使用JDK中的通用程序Keytool通过已知方法和密码创建秘锁和密钥。每次编译的时候，工具使用debug密钥签名应用程序的.apk文件。因为密码是已知的，工具不需要在每次编译的时候提示输入密锁和密钥。
·当应用程序调试完毕准备要发布release版本时，可以在release模式下编译。release模式下，编译工具不会将.apk文件签名。需要自己用Keytool生成密钥和密锁，再用JDK中的Jarsigner工具给.apk文件签名。签名基本设置 首先设置java_HOME环境变量，告诉SDK如何找到Keytool，或者可以在Windows 系统环境变量PATH变量中添加Keytool的JDK路径。
在发布release版本时，从Package面版上按选中你的project，按鼠标右键，依次选择Android Tools、Export Application Package。或者可以点击Manifest Editor，overview 页面上的“Exporting the unsigned .apk”连接 ，导出未签名apk文件。保存.apk文件后，用Jarsigner及自己的密钥给apk文件签名，如果没有密钥， 可以用Keystore创建密钥和密锁。如果已经有一个密钥了，如公共密钥，就可以给.apk文件签名了。也可以把上面这个完整的步骤写成一个bat文件，这样需要签名的时候只要运行这个bat就可以了。下面给出一个完整的bat文件示例：
@Rem android签名程序 //注释指令
@Rem echo是显示指令 格式：echo [{on|off}] [message]
@echo **********************************************************
@Rem 文件是否存在命令格式：if exist 路径+文件名 命令
@if exist d:sign/MyFirstApp.keystore goto sign
@echo 创建签名文件MyFirstApp.keystore
@Rem keytool命令格式：-genkey产生签名 -alias别名 -keyalg加密算法 -validity有效天数 -keystore生产签名文件名称
keytool -genkey -alias MyFirstApp.keystore -keyalg RSA -validity 40000 -keystore MyFirstApp.keystore
@echo 开始签名：
@Rem jarsigner命令格式：-verbose输出详细信息 -keystore密钥库位置 -signedjar要生成的文件 要签名的文件 密钥库文件
jarsigner -verbose -keystore MyFirstApp.keystore -signedjar MyFirstApp_signed.apk MyFirstApp.apk MyFirstApp.keystore@goto over:sign@echo 开始签名：
jarsigner -verbose -keystore MyFirstApp.keystore -signedjar MyFirstApp_signed.apk MyFirstApp.apk MyFirstApp.keystore：over@echo ********************MyFirstApp.apk 签名完成************************pause================以上是一个给应用签名的完整bat文件，在运行这个bat文件时，还需要按照屏幕提示的步骤输入一些必要信息，最后生成一个签名后的文件是：MyFirstApp_signed.apk。签名完成以后最好再把这个文件压缩一下，使用Android SDK安装路径下tools文件夹里的zipalign进行压缩，以刚才这个文件为例，也可以写成一个bat文件，示例如下：
D:\soft\android-sdk-windows\tools\zipalign -c -v 4 MyFirstApp_zip.apkpause================上面的D:\soft\android-sdk-windows用你的实际Android SDK安装路径代替。按照以上步骤签名、压缩就完成了，最后把压缩后的那个文件(比如例子中的MyFirstApp_zip.apk文件)复制到手机上就可以正常的安装运行了。

② 互联网上的加密原理

互联网上的加密方式主要分为对称加密和非对称加密二种，

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。
需要对加密和解密使用相同密钥的加密算法。由于其速度快，对称性加密通常在消息发送方需要加密大量数据时使用。对称性加密也称为密钥加密。
所谓对称，就是采用这种加密方法的双方使用方式用同样的密钥进行加密和解密。密钥是控制加密及解密过程的指令。算法是一组规则，规定如何进行加密和解密。
加密的安全性不仅取决于加密算法本身，密钥管理的安全性更是重要。因为加密和解密都使用同一个密钥，如何把密钥安全地传递到解密者手上就成了必须要解决的问题。
常用的对称加密有：DES、IDEA、RC2、RC4、SKIPJACK、RC5、AES算法等

非对称加密算法需要二个秘钥，公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

明白了互联网上的加密原理之后，下面来看看浏览器与服务器交互时，浏览器想将数据加密后再发送给服务器，那么该怎么做呢？服务器首先要向浏览器出示一份数字证书，浏览器看到数字证书后，就可以使用数字证书里面的公钥加密数据，所以要想做浏览器和服务器的加密数据传输，那么首先得针对服务器生成一份数字证书。然后再配置一下服务器，让服务器收到浏览器的请求之后，会向浏览器出示它的数字证书。

SUN公司提供了制作证书的工具keytool， 在JDK 1.4以后的版本中都包含了这一工具，它的位置为<JAVA_HOME>\bin\keytool.exe

使用keytool生成一个名字为tomcat的证书，存放在.keystore这个密钥库中

③ 关于公私钥、各种证书、https基本概念扫盲

最近实习需要写一些生成证书的脚本，借此机会顺便搞清楚了许多关于证书这块的疑惑。说到这一块东西，名词多到爆炸，对称加密、非对称加密、密钥、密钥库、公钥、私钥、CA、证书、数字签名、ssh、https、ssl、keytool、openssl、PKCS、X.509以及令人眼花缭乱的文件后缀名，cer、crt、pem、keystore、jks、key、p12、pfx...

先听我讲个故事，这次我们不用Bob和Alice,听完之后再去看这些概念，绝壁恍然大悟。

故事背景: 这是2018年，为了能够安全的进行通信，假设每个人都有俩把锁，一个叫A锁，一个叫B锁，这俩把锁和一般的锁有点区别，每把锁上即带有自己的锁孔又带有另一把锁的钥匙，因此A锁和B锁既是锁又是钥匙。 A锁和B锁唯一配对，A锁锁住之后，只有B锁可以打开，同样B锁锁住之后，只有A锁可以打开 。其中一把锁是公开的，而一把锁则自己保管，不公开。假设默认A锁是公开的，B锁是私有的。

故事内容: 阿里巴巴子弟小学的小明想给隔壁班的小花写封表白信，为了不被别人看到，他将信放入在信箱中，并用小花的A锁将信箱锁住，因为小花的B锁(同是A锁的钥匙)只有小花自己有，所以除了小花以外的任何人拿到信件，都无法看到信件内容。同样小花要给小明写信，那么也要用小明的A锁对信件内容进行保护。

小明与小花通过就这样聊了有一段时间，后来小花觉得差不多了，可以进入秀恩爱的阶段了，跟小明说，以后写信别tm加密了，又不是银行卡密码，被人看到又能怎么样呢？只要看了之后别瞎改就行了。于是小明在写完信后，把信里每个字的拼音首字母拼凑了一个字符串，并取名为 消息摘要 ，然后仅仅将消息摘要放入信箱，用自己的B锁锁住这个信箱。虽然信件本身没有放入安全的信箱，但小明作为一个情书高手，随便一封信都是上万字，如果其他人对信件内容做任何改变，那么拼音首字母组成的字符串几乎肯定会改变，因此小花拿到信件后，先用小明的A锁(B锁的钥匙)打开信箱，拿到小明的摘要,然后小花再对信件内容做同样的处理(即计算信件每个字的拼音首字母，实际上不会用这么简单的算法，而是会用不可逆的hash算法)，计算出的字符串值如与小明的信息摘要一致，说明这封信就是小明写给自己的，没有被任何人篡改。

故事高潮: 事情并没有那么简单，小花发现小明只是在信件里对自己热情似火，平常见了面连声招呼都不打，一副不认识的样子。终于有一天小花忍不住了，当面质问小明，小明却说，我什么时候给你写情书了，自作多情吧...于是小花把昨天刚收到的情书狠狠甩在了小明脸上:“上面落款不是你小明吗？怎么了,怂了？”小明一看上面还真是自己的名字，但是自己写没写信自己还不知道吗？小明把自己的作业本拿给小花，并叫自己的同桌做笔迹鉴定，小花发现笔迹的确不大像，看来是有人恶作剧，冒充小明给自己写情书，哎，好尴尬啊。。。

故事讲完了，文章开头涉及的所有概念都与信息的安全传输有关，可以说，一切都是为了安全。关于通信安全，我们通常有三个基本的需求

我们以上面的故事为例说一下这三点安全需求，一开始小明与小花通过A锁( 对应公钥 )加密,B锁( 对应私钥 )解密的通信方式即符合第一点，信件内容本身被加密，而因为公私钥唯一配对，只有配对的密钥才可以解密，因此很难被第三人破解。

之后，为了秀恩爱，他们采用了B锁( 私钥 )加密，A锁( 公钥 )解密的通信方式，其中用私钥对消息摘要加密后的字符串称为 数字签名 ,这样虽然信件可以被人直接看到，但如果被人篡改掉后可以轻易发现数据被篡改。本来以为满足第一条和第二条就可以安全的通信了，但最后才发现小明根本不是小明！为什么会出现这样的问题？因为“小明”说他是小明，小花就以为他是小明，他没有提供任何证明自己真的是小明的认证。因此要想安全通信，我们还需要一个权威第三方的机构来做身份认证,这个机构就是CA机构，通过认证后，CA机构会颁发权威的证书，而有了证书就可以证明身份，就不会出现身份被假冒的情况。而认证的过程则需要向CA机构提供自己的身份信息以及私钥。

对称加密就是通信双方或多方采用的密钥是一样的。加解密速度快，但不够安全。因为一旦密钥泄露，谁都可以对数据进行解密。非对称加密就是当然就是通信双方使用的密钥不同。而公钥和私钥就是非对称加密的一种方式。比较常用的对称加密算法如
AES、DES，非对称加密比较常见的则有sha256,RSA。
非对称加密算法有俩个密钥，一个公钥，一个私钥。公钥和私钥必须配对出现，一对公钥和一个私钥统称为一个 密钥 ，而 密钥库 中可以存放多个密钥，即多对公私钥。

如果你用github的话，应该注意到github链接有俩种方式。一种是https,一种是ssh,通过https经常需要输密码，而通过ssh则不需要。回忆你设置ssh的步骤，本地生成了一个密钥对，并将公钥上传到了github。每次传输用自动本地私钥加密，服务器用你上传的公钥解密，就不需要手动输入密码了。

keytool和openssl是俩个证书管理工具.keytool是java JDK自带的证书管理工具，使用keytool可以生成密钥，创建证书。只要装了jdk,并正确设置了环境变量，就可以之间通过命令行执行keytool命令来管理证书。
openssl则是一个开源的安全套接字层密码库，功能比keytool更加丰富。

PKCS全称Public-Key Cryptography Standards 即公钥标准，PKCS已经发布了15个标准。
PKCS#12 包含了公钥和私钥的二进制格式的证书形式，以pfx作为证书文件后缀
X.509 则是一个通用的证书标准，规定了证书应该包含哪些内容，X.509通常有俩种编码方式，一种是二进制编码，另一种是base64编码
X.509#DER 二进制格式证书，常用后缀.cer .crt
X.509#PEM 文本格式证书，常用后缀.pem

因为http是明文传输，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)层协议，即在原来的基础上又加了一层协议用于保障安全传输,可以认为https=ssl+http。很多人刚开始接触https，用浏览器F12打开控制台后。可能发现数据仍然没有加密。要注意https是 传输层加密 ，浏览器F12控制台你看到的还是应用层的数据。
因为本文主要是概念扫盲，帮助理解，因此关于这部分具体细节不作介绍。

.keystore和.jks和.truststore都是java用来存放密钥的文件
.key nginx中私钥文件
而不同的证书文件后缀都是为了区分不同种类的证书的，主要有俩个分类维度

④ 如何指定 https的加密算法

一般采用SHA 256 RSA加密算法，如果需要ECC算法，好像证书颁发机构GDCA也可以指定算法，你把自己的需求问下他们技术客服。

⑤ APK签名机制原理详解

众所周知，Android系统在安装Apk的过程中，会对Apk进行签名校验，校验通过后才能安装成功。那你知道签名校验的机制是什么？具体校验的是什么内容吗？申请第三方SDK（如微信支付）时填入的SAH1值是什绝颂高么？目前众多的快速批量打包方案又是如何绕过签名检验的？

我将通过一系列的文章来解开这些疑惑：

这篇文章先来介绍Apk签名相关的基本知识。

要知道签名是什么，先来看为什么需要签名 。大家都知道，在消息通信时，必须至少解决两个问题：一是确保消息来源的真实性，二是确保消息不会被第三方篡改。在安装Apk时，同样需要确保Apk来源的真实性，以及Apk没有被第三方篡改。如何解决这两个问题呢？方法就是开发者对Apk进行签名：在Apk中写入一个“指纹”。指纹写入以后，Apk中有任何修改，都会导致这个指纹无效，Android系统在安装Apk进行签名校验时就会不通过，从而保证了安全性。

要了解如何实现签名，需要了解两个基本概念：数字摘要和数字证书。

简单来说，就是对一个任意长度的数据，通过一个Hash算法计算后，都可以得到一个固定长度的二进制数据，这个数据就称为“摘要”。摘要具有下面的几个特征：

前面已经说到，可以通过签名来确保数据来源的可靠性和数据的不可篡改性。签名就是在摘要的基础上再进行一次加密，对摘要加密后的数据就可以当作数字签名，在安装Apk需要对签名进行验证，验证通过才能继续安装。

这里有两个过程：签名过程 和 校验过程。

先来说 签名过程：

再来看 校验过程：

这里有一个前提：接收方必须要知道发送方的公钥和所使用的算法。如果数字签名和公钥一起被篡改，接收方无法得知，还是会校验通过。如何保证公钥的可靠性呢？答案是数字证书，数字证书是身份认证机构（Certificate Authority）颁发的，包含了以下信息：

接收方收到消息后，先向CA验证证书的合法性（根据证书的签名、绑定的域名等信息。CA机构是权威的，可以保证这个过程的可靠性。）再进行签名校验。

需要注意的是，Apk的证书通常的自签名的，也就是由开发者自己制作，没有向CA机构申请。Android在安装Apk时并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，这也正是对第三方Apk重新签名后，还能够继续在没有安装这个Apk的系统中继续安装的原因。

我们在对Apk签名时并没有直接指定私钥、公钥和数字证书，而是使用keystore文件，这些信息都包含在了keystore文件中。根据编码不同，keystore文件分为很多种，Android使用的是Java标准keystore格式JKS(Java Key Storage)，所以通过Android Studio导出的keystore文件是以.jks结尾的。

keystore使用的证书标准是X.509，X.509标准也有多种编码格式，常用的有两种：pem（Privacy Enhanced Mail）和der（Distinguished Encoding Rules）。jks使用的是der格式，Android也支持直接使用pem格式的证书进行签名，我们下面会介绍。

两种证书编码格式的区别：

X.509证书格式：

Android提供了两种对Apk的签名方式，一种是基于JAR的签名方式，另一种是基于Apk的签名方式，它们的主要区别在于使用的签名文件不一样：jarsigner使用keystore文件进行签名；apksigner除了并尺支持使用keystore文件进行签名外，还支持直接指定pem证书文件和私钥进行签名。

不知道大家有没有注意一个问题，我们通过樱御keytool或者AS生成一个keystore的时候（ 签署您的应用 ），除了要输入keystore的密码外，还要输入一个alias和key的密码。在签名时，除了要指定keystore文件和密码外，也要指定alias和key的密码，这是为什么呢？

原因是keystore是一个密钥库，也就是说它可以存储多对密钥和证书，keystore的密码是用于保护keystore本身的，一对密钥和证书是通过alias来区分的。从这里可以看出jarsigner是支持使用多个证书对Apk进行签名的。apksigner也同样支持，关于apksigner的使用介绍可以参考官方文档 apksigner 。

ok，签名的基本概念和校验过程就介绍到这里，关于JAR签名和V2签名机制的详细介绍，参考下面两篇文章：

⑥ 一文弄懂关于证书，签名，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协议基于证书来实现。