"数字签名"（digital signature）和"数字证书"（digital certificate）到底是什么

简介

和阮一峰一样，我也是 ：对"数字签名"（digital signature）和"数字证书"（digital certificate）到底是什么有些模糊。仔细阅读之后记录一下。

数字签名最初的目的是解决内容加密和身份鉴别的。

过程是：发件人把发件的内容做摘要，然后用私钥加密。把内容，摘要、给收件人，收件人用自己的公钥解密，证明信件是受到信任的发件人发的。然后用同样的算法对内容做摘要和收到的摘要对比，发现一致。证明没有修改过。

但是，坏人来了！

坏人入侵了你的邮箱（也可以理解为电脑、手机），把发件人发出的公钥改成了自己的公钥，这样，坏人呢用自己的私钥加密的内容发送给你，你也可以解密，也可以『假装』认为也是 我信任的人发送的。

所以数字证书来了，数字证书解决的就是 公钥受信任的问题！！！

它可以用来加密连接和加密内容！

数字证书如何颁发的

数字证书如何颁发的.png

证书颁发

1/ 首先撰写证书的元信息：签发人(Issuer)、地址、签发时间、过期失效等；当然，这些信息中还包含证书持有者(owner)的基本信息，例如owner的DN(DNS Name，即证书生效的域名)，owner的公钥等基本信息。
2/ 通过通用的Hash算法将信息摘要提取出来；
3/ Hash摘要通过Issuer(CA)私钥进行非对称加密，生成一个签名密文；
4/ 将签名密文attach到文件证书上，使之变成一个签名过的证书。
也就是说，数字证书包含了 证书所有人信息以及证书所有人信息进过摘要并且经过CA 进行非对称加密之后的密文的这么一个数字文件。

证书的验证

1/ 客户端、浏览器获得之前签发的证书；
2/ 将其解压后分别获得“元数据”和“签名密文”；
3/ 将同样的Hash算法应用到“元数据”获取摘要；
4/ 将密文通过Issuer(CA)的公钥（非对称算法，私钥加密，公钥解密）解密获得同样的摘要值。
5/ 比对两个摘要，如果匹配，则说明这个证书是被CA验证过合法证书，里面的公钥等信息是可信的。

整个过程如下：

数字证书验证.png

也就是说数字证书验证的时候，使用证书中包含的证书所有者信息、经过CA加密过的密文、CA的公钥等来验证。

说到这，就知道了下面受信任的根证书，到底是作何用的了！！！

受信任的根证书

数字证书的分类

证书有很多类型，首先分为三种认证级别。

1/ 域名认证（Domain Validation）：最低级别认证，可以确认申请人拥有这个域名。对于这种证书，浏览器会在地址栏显示一把锁。
2/ 公司认证（Company Validation）：确认域名所有人是哪一家公司，证书里面会包含公司信息。
3/ 扩展认证（Extended Validation）：最高级别的认证，浏览器地址栏会显示公司名。

按照覆盖范围分类

1/ 单域名证书：只能用于单一域名，foo.com的证书不能用于www.foo.com
2/ 通配符证书：可以用于某个域名及其所有一级子域名，比如*.foo.com的证书可以用于foo.com，也可以用于www.foo.com
3/ 多域名证书：可以用于多个域名，比如foo.com和bar.com

证书链

HTTPS的核心就是证书链，证书链的“信任”核心是CA。

如下图，在浏览器打开baidu.com，会发现它使用的是https连接，有一个绿色的小锁。

Paste_Image.png

baidu使用的HTTPS证书，除了HTTPS使用的 baidu.com 证书，向上还有两级证书，证书有3类：
1/ end-user ：baidu.com 包含用来加密传输数据的公钥的证书，是HTTPS中使用的证书
2/ intermediates：CA用来认证公钥持有者身份的证书，即确认HTTPS使用的end-user证书是属于baidu.com的证书。这类intermediates证书甚至可以有很多级。
中间证书的含义：
https://sg.godaddy.com/en/help/what-is-an-intermediate-certificate-868
3/ root：用来认证intermediates证书是合法证书的证书。
简单来说，end-user证书上面几级证书都是为了保证end-user证书未被篡改，保证是CA签发的合法证书，进而保证end-user证书中的公钥未被篡改。

除了end-user之外，证书被分为root Certificates和intermediates Certificates。相应地，CA也分了两种类型：root CAs 和 intermediates CAs。首先，CA的组织结构是一个树结构，一个root CAs下面包含多个intermediates CAs，而intermediates又可以包含多个intermediates CAs。root CAs 和 intermediates CAs都可以颁发证书给用户，颁发的证书分别是root Certificates和intermediates Certificates，最终用户用来认证公钥的证书则被称为end-user Certificates。

证书链验证

如何保证，end user使用的公钥是合法的呢？

Paste_Image.png

参考：https://www.pianyissl.com/support/page/10

数字证书结构

最常用的 是 X.509证书的结构
1、X.509证书基本部分
1.1. 版本号.
标识证书的版本（版本1、版本2或是版本3）。

1.2. 序列号
标识证书的唯一整数，由证书颁发者分配的本证书的唯一标识符。

1.3. 签名
用于签证书的算法标识，由对象标识符加上相关的参数组成，用于说明本证书所用的数字签名算法。例如，SHA-1和RSA的对象标识符就用来说明该数字签名是利用RSA对SHA-1杂凑加密。

1.4. 颁发者
证书颁发者的可识别名（DN）。

1.5. 有效期
证书有效期的时间段。本字段由”Not Before”和”Not After”两项组成，它们分别由UTC时间或一般的时间表示（在RFC2459中有详细的时间表示规则）。

1.6. 主体
证书拥有者的可识别名，这个字段必须是非空的，除非你在证书扩展中有别名。

1.7. 主体公钥信息
主体的公钥（以及算法标识符）。

1.8. 颁发者唯一标识符
标识符—证书颁发者的唯一标识符，仅在版本2和版本3中有要求，属于可选项。

1.9. 主体唯一标识符
证书拥有者的唯一标识符，仅在版本2和版本3中有要求，属于可选项。

2、X.509证书扩展部分
可选的标准和专用的扩展（仅在版本2和版本3中使用），扩展部分的元素都有这样的结构：

Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
extnID：表示一个扩展元素的OID

critical：表示这个扩展元素是否极重要

extnValue：表示这个扩展元素的值，字符串类型。

扩展部分包括：

2.1. 发行者密钥标识符
证书所含密钥的唯一标识符，用来区分同一证书拥有者的多对密钥。

2.2. 密钥使用
一个比特串，指明（限定）证书的公钥可以完成的功能或服务，如：证书签名、数据加密等。

如果某一证书将 KeyUsage 扩展标记为“极重要”，而且设置为“keyCertSign”，则在 SSL 通信期间该证书出现时将被拒绝，因为该证书扩展表示相关私钥应只用于签写证书，而不应该用于 SSL。

2.3. CRL分布点
指明CRL的分布地点。

2.4. 私钥的使用期
指明证书中与公钥相联系的私钥的使用期限，它也有Not Before和Not After组成。若此项不存在时，公私钥的使用期是一样的。

2.5. 证书策略
由对象标识符和限定符组成，这些对象标识符说明证书的颁发和使用策略有关。

2.6. 策略映射
表明两个CA域之间的一个或多个策略对象标识符的等价关系，仅在CA证书里存在。

2.7. 主体别名
指出证书拥有者的别名，如电子邮件地址、IP地址等，别名是和DN绑定在一起的。

2.8. 颁发者别名
指出证书颁发者的别名，如电子邮件地址、IP地址等，但颁发者的DN必须出现在证书的颁发者字段。

2.9. 主体目录属性
指出证书拥有者的一系列属性。可以使用这一项来传递访问控制信息。

证书的验证

方法1

Paste_Image.png

结果如下，有类似 verify error:这样的信息肯定是不对的。属于服务器配置问题。

depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=21:unable to verify the first certificate
verify return:1
read from 0x7fa415e00170 [0x7fa416806600] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 04 .....
read from 0x7fa415e00170 [0x7fa416806605] (4 bytes => 4 (0x4))
0000 - 0e .
0004 -

方法2
https://tools.keycdn.com/ssl

客户端使用

没经过 CA 认证的自签证书的验证 和 CA 认证的证书链的验证方式是一样，不同点在不可信锚点的证书类型不一样而已：前者的锚点是自签的需要被打包进 App 用于验证，后者的锚点可能本来就存在系统之中了。

安卓端使用：http://xhrwang.me/2015/06/06/https-and-android.html

参考：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html