一文弄懂关于证书，签名，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包内的certsf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。

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

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

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

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

第三方平台会记录 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协议基于证书来实现。

本文主要是简单介绍了常见的加密类型、各自的运用场景、为什么需要数字签名和数字证书、HTTPS涉及到的加密流程等。这里主要从使用者的角度出发，对算法本身不做过多介绍。

对称/非对称加密均属于 可逆加密，可以通过密钥将密文还原为明文 。

有时候，我们希望明文一旦加密后，任何人（包括自己）都无法通过密文逆推回明文，不可逆加密就是为了满足这种需求。

不可逆加密主要通过 hash算法实现：即对目标数据生成一段特定长度hash值 ；无论你的数据是1KB、1MB、1GB，都是生成特定长度的一个Hash值（比如128bit）。这里大家应该能感受到一点 不可逆 的味道，加密后128bit的hash值显然无法还原出1个G甚至更大的不规则数据的， hash可以看做是原来内容的一个摘要 。

常见算法：

小明给小红写信：

经过九转十八弯后，信的内容有可能：1 被窥视 2 被篡改（冒充小明发送假消息） ：

小红先 生成对称加密的密钥key1 ，然后通过一个安全的渠道交予小明。

传输数据时，小明 使用key1加密 ，而小红收到后再 使用key1解密 。

这时候 中间者既看不到原来的内容，也没办法篡改 （因为没有密钥）：

对称加密实现简单，性能优秀 ，算法本身安全级别高。然而对 密钥的管理 却是个很头疼的问题：一旦密钥交到对方手里，对方对密钥的保管能力 我方是没办法控制 的，一旦对方泄露的话，加密就形同虚设了。

相对而言，非对称加密的公钥就没有这个忧虑，因为 公钥 的设计就是为了 可以公开的 ，尽管对方泄露，我方也不会有任何损失。

小红生成一对公私钥，自己持有私钥（pri_key1），将公钥（pub_key1）交予小明。

传输数据时，小明使用 公钥加密 ，小红使用 私钥解密 。

因为 中间者没有私钥，公钥加密的内容是无法获取的 。此时达到了 防窥视 的效果：

然而因为 公钥是可以公开的 ，如果 中间者知晓公钥 的话，尽管没有办法看到原来的内容，却 可以冒充小明发送假消息 ：

这时小红在想，如果小明发送消息时，能带上 只有他自己才能生成 的数据（字符串），我就能 验证是不是小明发的真实消息 了。

通常这个 能证实身份的数据（字符串） 被称之为 数字签名（Signature）

小明再生成一对公私钥 ，自己持有私钥（pri_key2），将公钥交予小红（pub_key2）。

当小明传输数据时（可能很大），除了公钥加密明文之外，还要带上签名：(1) 对明文做一个hash摘要 (2)对摘要进行私钥加密，加密结果即签名（传输内容=内容密文+签名）

小红收到后：(1) 解密签名获取hash (2)解密内容密文，对解密后的明文进行hash；如果两个hash一致，说明验签通过。

尽管中间者修改了传输内容，但因为签名无法冒认（没有私钥），小红验签失败，自然不会认可这份数据：

通常 非对称加密要做到防窥视和防篡改，需要有两对公私钥 ：对方的公钥用于内容加密，自己的私钥用于签名（让对方验证身份）。

因为HTTP协议明文通信的安全问题，引入了HTTPS：通过建立一个安全通道（连接），来保证数据传输的安全。

服务器是 没办法直接将密钥传输到浏览器的 ，因为在 安全连接建立之前，所有通信内容都是明文的 ，中间者可窥视到密钥信息。

或许这时你想到了非对称加密，因为公钥是不怕公开的：

然而在第2步， 中间者可以截取服务器公钥，并替换成了自己的公钥 ，此时加密就没意义了：

为了 防止公钥被假冒，数字证书（digital certificate ）便诞生了 。

当服务器需要告诉浏览器公钥时，并不是简单地返回公钥，而是响应 包含公钥信息在内的数字证书 。

证书主要包含以下内容：

浏览器通过 颁发机构的公钥进行解密验签 ，验签通过即说明证书的真实性，可以放心取 证书拥有者的公钥 了。（ 常用CA机构的公钥都已经植入到浏览器里面 ）

数字证书只做一件事： 保证 服务器响应的 公钥是真实的 。

以上保证了 [浏览器⇒服务器] 是加密的，然而 [服务器⇒浏览器] 却没有（上图第4步）；另外一个是 性能问题 ，如果所有数据都使用非对称加密的话，会消耗较多的服务器资源，通信速度也会受到较大影响。

HTTPS巧妙地结合了非对称加密和对称加密，在保证双方通信安全的前提下，尽量提升性能。

HTTPS（SSL/TLS）期望 建立安全连接后，通信均使用对称加密 。

建立安全连接的任务就是让 浏览器-服务器协商出本次连接使用的对称加密的算法和密钥 ；协商过程中会使用到非对称加密和数字证书。

特别注意的是：协商的密钥必须是不容易猜到（足够随机的）：

其中比较核心的是随机数r3（pre-master secret），因为之前的r1、r2都是明文传输的， 只有r3是加密传输 的。至于为什么需要三个随机数，可以参考：

以上是一个比较简单的HTTPS流程，详细的可以参考文末的引用。

参考资料：

[1] 数字证书应用综合揭秘

[2] SSL/TLS协议运行机制的概述

[3] 图解SSL/TLS协议

[4] 《图解HTTP》

数字签名采用的是非对称加密技术。

非对称加密技术，也称为公钥加密，使用两个密钥进行加密和解密操作，分别是公钥和私钥。公钥是公开的，任何人都可以使用，而私钥是保密的，只有密钥的主人才能使用。这种加密方式的主要优点是安全性高，因为私钥只有密钥的主人掌握，即使公钥被攻击者获取，也无法解密出原始信息。

在数字签名中，发送方使用自己的私钥对信息进行加密，生成数字签名，然后将数字签名和信息一起发送给接收方。接收方使用发送方的公钥对数字签名进行解密，验证信息的完整性和真实性。因为私钥只有发送方掌握，因此只有发送方才能生成有效的数字签名，这样可以确保信息的来源和完整性。

举个例子，假设小明要给小红发送一条加密信息。小明使用自己的私钥对信息进行加密，生成数字签名，然后将数字签名和信息一起发送给小红。小红收到信息后，使用小明的公钥对数字签名进行解密，验证信息的完整性和真实性。如果解密成功，说明信息确实是小明发送的，并且没有在传输过程中被篡改。

总之，数字签名采用的是非对称加密技术，使用公钥和私钥进行加密和解密操作，可以确保信息的来源和完整性。

电子签名和加密技术，电子签名技术的实现需要使用到非对称加密（RSA算法）和报文摘要（HASH算法）。

非对称加密是指用户有两个密钥，一个是公钥，一个是私钥，公钥是公开的，任何人可以使用，私钥是保密的，只有用户自己可以使用，公钥和私钥是对应关系。用户可以用对方的公钥加密信息，并传送给对方，对方使用自己的私钥将密文解开。公私钥是互相解密的，而且绝对不会有第三者能插进来。

报文摘要利用HASH算法对任何要传输的信息进行运算，生成128位的报文摘要，而不同内容的信息一定会生成不同的报文摘要，因此报文摘要就成了电子信息的“指纹”。

有了非对称加密技术和报文摘要技术，就可以实现对电子信息的电子签名了。 文档电子签名软件是一种电子盖章和文档安全系统，可以实现电子盖章(即数字签名)、文档加密、签名者身份验证等多项功能。对于签名者的身份确认、文档内容的完整性和签名不可抵赖性等问题的解决具有重要作用。

使用数字证书对Word文档进行数字签名，保证签名者的签名信息和被签名的文档不被非法篡改。签名者可以在签名时对文档签署意见，数字签名同样可以保证此意见不被篡改。

软件应嵌入Word环境，集成为应用组件，使用简便，界面友善。操作生成的数字签名和意见以对象方式嵌入Word文档，直观明了。

软件还应支持多人多次签名，每个签名可以在文档中的任意位置生成，完全由签名者控制。

软件避免采用宏技术，从而避免因用户禁用宏而导致软件失效。

数字签名使用的数字证书可以存储在智能卡和USB电子令牌之类的硬件设备中，这些存储介质自身有安全性高、携带方便等特点，进一步提高了系统的安全性。

在企业中，对于往来的需审批的重要文档，必须保持其安全、有效，并要求留下审批者的意见及签名，如果采用传统的方法如传真，势必造成大量的扫描文件需要存储，且不好管理，而电子签名在安全体系的保证下，将为文档管理的效率带来显著的提高。由此看来，采用先进的IT技术，能推动我们的办公无纸化进一步的向前发展。