客户端认证https服务端证书过程详解——证书链

基本概念

证书

首先，我们看看在wikipedia上对证书的定义，In cryptography, a public key certificate (also known as a digital certificate or identity certificate) is an electronic document used to prove ownership of a public key.。可以这么说，证书是用来认证公钥持有者的身份的电子文档，防止第三方进行冒充。一个证书中包含了公钥、持有者信息、证明证书内容有效的签名以及证书有效期，还有一些其他额外信息。

比如一个证书详细信息的截图：

CA

我们用证书来认证公钥持有者的身份，那证书是怎么来的呢？又该怎么认证证书呢？这涉及到一个称之为PKI(Public key certificate)的规范体系，包含了数字证书，公钥管理以及验证等技术，详细可以参考：https://en.wikipedia.org/wiki/Public_key_certificate ，我们这里只是简单介绍一下概念。在阮老师的文章中，提到证书要由证书中心(Certificate authority，简称CA)签发的，同样参考Wikipedia上的概念，In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. (https://en.wikipedia.org/wiki/Certificate_authority) ，简单来说，CA就是签发电子证书的实体。

Signing & Verification

证书的签发(Signing)和认证(Verification)的过程：

这两个过程也是基于公钥与私钥的，签发和认证的过程跟传输信息过程中的加密解密过程非常类似。签名密文(Signature)是一个重要凭证，Signature与签发人的公钥一同传输，可以避免中间人在获取证书时对证书内容的篡改。参考：http://blog.torchz.net/security/2014/12/23/security-ca-chain-of-trust.html 。

签发证书的步骤：

1. Signing阶段，首先撰写证书的元信息：签发人(Issuer)、地址、签发时间、过期失效等；当然，这些信息中还包含证书持有者(owner)的基本信息，例如owner的DN(DNS Name，即证书生效的域名)，owner的公钥等基本信息。
2. 通过Issuer(CA)的证书指定的Hash算法将信息摘要提取出来；
3. Hash摘要通过Issuer(CA)私钥进行非对称加密，生成一个签名密文；
4. 将签名密文attach到文件证书上，使之变成一个签名过的证书。

验证证书的步骤：

1. Verification阶段，浏览器获得之前签发的证书；
2. 将其解压后分别获得“元数据”和“签名密文”；
3. 将Issuer(CA)的证书指定的Hash算法应用到“元数据”获取摘要A；
4. 将"签名密文"通过Issuer(CA)的公钥解密获得摘要B。
5. 比对摘要A和摘要B，如果匹配，则说明这个证书是被CA验证过合法证书，里面的公钥等信息是可信的。

在Verification阶段，解密Signature获得摘要需要通过签发者(Issuer)的公钥，又该如何获得这个公钥，同时确保这个公钥是有效的呢？就是下面的证书链的内容

证书链

实例

在Chrome上任意打开一个支持HTTPS的网站，例如 https://www.baidu.com/ ，打开开发者工具，点开Security栏

点开证书路径，查看证书信息如下：

我们继续探究baidu使用的HTTPS证书，除了HTTPS使用的 baidu.com 证书，向上还有两级证书，证书有3类：

• end-user ：baidu.com 包含用来加密传输数据的公钥的证书，是HTTPS中使用的证书
• intermediates：CA用来认证公钥持有者身份的证书，即确认HTTPS使用的end-user证书是属于baidu.com的证书。这类intermediates证书甚至可以有很多级。
• root：用来认证intermediates证书是合法证书的证书。

简单来说，end-user证书上面几级证书都是为了保证end-user证书未被篡改，保证是CA签发的合法证书，进而保证end-user证书中的公钥未被篡改。

CA组织

除了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 certificates & intermediates certificates

我们使用end-user certificates来确保加密传输数据的公钥(public key)不被篡改，而又如何确保end-user certificates的合法性呢？这个认证过程跟公钥的认证过程类似，首先获取颁布end-user certificates的CA的证书，然后验证end-user certificates的signature。一般来说，root CAs不会直接颁布end-user certificates的，而是授权给多个二级CA，而二级CA又可以授权给多个三级CA，这些中间的CA就是intermediates CAs，它们才会颁布end-user certificates。

但是intermediates certificates的可靠性又如何保证呢？这就是涉及到证书链，Certificate Chain ，链式向上验证证书，直到Root Certificates，如下图：

root certificates

那Root Certificates又是如何来的呢？根据 https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/ 这篇文章的说法，除了可以下载安装之外，device（例如浏览器，操作系统）都会内置一些root certificates，称之为trusted root certificates，https://support.apple.com/en-us/HT202858 ，在Apple的官网上可以看到这个列表，有各个操作版本直接内置的Root Certificates。windows系统查看方式可以看这篇文章：windows查看系统证书

最后一个问题，为什么需要证书链这么麻烦的流程？Root CA为什么不直接颁发证书，而是要搞那么多中间层级呢？找了一下，godaddy官方给了一个答案，为了确保root certificates的绝对安全性。我们可以想想，如果根证书的私钥泄露了，所有使用该证书认证的设备都将变得不安全，影响太大，所以通过intermediates certificates给网站颁发证书，假如某个intermediates certificates的私钥泄露了，只会影响这一个intermediates certificates颁发的证书的信用，影响要小很多。https://sg.godaddy.com/en/help/what-is-an-intermediate-certificate-868 ，将根证书隔离地越严格越好。

其他

了解了这个证书体系之后，才明白为什么百度/google这种公司也需要向第三方购买签名证书了，自签root证书推广起来非常困难，这也导致目前的证书市场基本上被 Symantec(VeriSign/GeoTrust) / Comodo / GoDaddy 垄断。百度使用的是Versign，google使用的是GeoTrust。目前HTTPS的推广已经不可避免，也已经有一些公益组织开始提供免费、自动化、开放的证书签发服务，例如：Let’s Encrypt 。