HTTPS学习笔记：（3）一文彻底了解PKI与证书

1. PKI

PKI(public key infrastructure)的目标是实现不同成员在不见面的情况下进行安全通信，采用的模型是基于证书颁发机构（ certification authority或certificate authority， CA）签发
的证书。PKI体系结构如下图所示:

• 订阅人:指那些需要证书来提供安全服务的团体。
• 登记机构:主要是完成一些证书签发的相关管理工作。可以理解为代理机构
• 证书颁发机构:既CA，是指证书的颁发机构，它会在确
  认申请用户的身份之后签发证书。同时CA会在线提供其所签发证书的最新吊销信息，这样信赖方就可以验证证书是否仍然有效。
• 信赖方：指那些证书使用者，主要指那些需要通过证书在互联网上进行安全通信的最终用户。信赖方为了能够验证证书，必须收集信任的所有根CA证书。大多数的操作系统都提供一个根证书库，几乎所有的软件开发者都重用了底层操作系统提供的根证书库，唯一的例外是Mozilla，为了保证不同平台的兼容性，它维护了自己的根证书库。

2. 证书

证书是一个包含公钥、订阅人相关信息以及证书颁发者数字签名的数字文件。

2.1 证书的分类

证书分类主要包括下面的类型

1. 域名验证型（DV）

   • 只验证网站域名所有权
   • 仅能加密通信内容，不能向用户证明网站的真实身份
   • 适合无身份认证需求的网站，如larave_china等

2. 组织验证型（OV）

   • 需验证域名所有权和所属单位的真实身份。
   • 不仅能加密通信内容，还能向用户证明网站的真实性
   • 适应电子商务，企业等网站使用，如亚马逊商城

3. 扩展验证型（EV）

   • 严格的身份验证，最高安全级别
   • 提供通信内容加密与网站身份证明，浏览器状态显示单位名称。
   • 适合金融证券，银行等网站使用，比如工商银行

2.2 证书结构

从浏览器以及censys(https://censys.io/certificates) 都可以清洗的看到证书的信息：
浏览器上部分证书内容如下：

在censys上查询baidu的证书，部分内容如下（完整内容可查看：https://censys.io/certificates/ed68c58b63218e1d2aa63394b3f23eca26fe5884c9f2235ac2d4ab6edd2f064e/openssl）：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            2c:ee:19:3c:18:82:78:ea:3e:43:75:73
    Signature Algorithm: sha256WithRSAEncryption
        Issuer:
            commonName                = PRINTABLESTRING:GlobalSign Organization Validation CA - SHA256 - G2
            organizationName          = PRINTABLESTRING:GlobalSign nv-sa
            countryName               = PRINTABLESTRING:BE
        Validity
            Not Before: May  9 01:22:02 2019 GMT
            Not After : Jun 25 05:31:02 2020 GMT
        Subject:
            commonName                = PRINTABLESTRING:baidu.com
            organizationName          = PRINTABLESTRING:Beijing Baidu Netcom Science Technology Co., Ltd
            organizationalUnitName    = PRINTABLESTRING:service operation department
            localityName              = PRINTABLESTRING:beijing
            stateOrProvinceName       = PRINTABLESTRING:beijing
            countryName               = PRINTABLESTRING:CN
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b4:c6:bf:da:53:20:0f:ea:40:f3:b8:52:17:66:
                    .....
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Authority Information Access: 
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
                OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2

            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

            X509v3 Subject Alternative Name: 
                DNS:baidu.com, DNS:click.hm.baidu.com, DNS:cm.pos.baidu.com, 
                .............
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier: 
                76:B5:E6:D6:49:F8:F8:36:EA:75:A9:6D:5E:4D:55:5B:37:5C:FD:C7
            X509v3 Authority Key Identifier: 
                keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : BB:D9:DF:BC:1F:8A:71:B5:93:94:23:97:AA:92:7B:47:
                                38:57:95:0A:AB:52:E8:1A:90:96:64:36:8E:1E:D1:85
                    Timestamp : May  9 01:22:04.826 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:2C:7B:4D:C0:F9:85:47:8A:2D:0A:C0:79:
                                3B:D6:B4:B5:66:F8:AA:FB:82:58:AD:23:36:FE:16:BC:
                                A6:83:99:21:02:21:00:C0:2F:CD:9C:99:20:CB:7D:91:
                                5F:D2:8B:C6:13:10:73:B5:C1:54:03:33:41:9F:A6:6A:
                                C5:14:93:CF:69:2B:6B
    Signature Algorithm: sha256WithRSAEncryption
         aa:b9:cd:52:8e:dc:36:5d:47:d4:8b:f3:32:17:06:46:83:60:
         ...........

证书的字段信息主要包括基本信息，扩展信息，基本信息如下：

• 版本：证书一共有3个版本号，分别用0、 1、 2编码表示版本1、版本2和版本3。现在大
  部分的证书都采用版本3的格式。
• 序列号：每个CA用来唯一标识其所签发的证书。序列号需要是无序的（无法被预测）而且至少包括20位的熵。
• 签名算法：指明证书签名所用的算法，需要放到证书里面，这样才能被证书签名保护。
• 颁发者：证书颁发者的可分辨名称（ distinguished name， DN），这个
  字段比较复杂，根据不同的实体会包含许多部分。举例来说， Verisign根证书的可分辨名
  称是/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority；它
  包括了国家、组织和组织单位三个部分。
• 有效期：证书的有效期包括开始日期和结束日期，在这段时间内证书是有效的。
• 使用者：证书使用者的可分辨名称。
• 公钥：证书的公钥

扩展信息：
版本3引入了证书扩展。扩展信息如下：

• 使用者可选名称（Subject Alternative Name）：
  基本信息里的"使用者"字段只能支持与一个主机名进行
  绑定，无法同时处理多个身份信息。使用者可选名称扩展就是为了替换使用者字段，它
  支持通过DNS名称、 IP地址和URI来将多个身份绑定在一起。
• 名称约束：名称约束扩展可以限制CA签发证书的对象，这样命名空间就在可控范围内。这个功能非常有用，例如，它允许一个组织可以拥有一个二级CA，而这个CA只能签发这个公司所拥有的那些域名下的证书。有了这个限制,CA不能签发任意网站的证书
• 基础约束（Basic Constraints）：基础约束扩展用来表明证书是否为CA证书，同时通过路径长度（ path length）约束字段，来限制二级CA证书路径的深度
• 密钥用法（ Key Usage）：该扩展定义了证书中密钥可以使用的场景，这些场景已经定义好了，可以通过设置来让证书支持某个场景。例如CA证书一般都设置了证书签名者（ certificate signer）和CRL签名者（ CRL signer）。
• 扩展密钥用法(Extended Key Usage):为了更加灵活地支持和限制公钥的使用场景，该扩展可以通过该字段支持更多的场景。
• 证书策略（Certificate Policies）：该扩展包含了一个或多个策略，每个策略都包括一个OID和可选限定符（ qualifier）。限定符一般包括一个URI，从这个URI可以获得完整的策略说明。
• CRL分发点（CRL Distribution Points):该扩展用来确定证书吊销列表（ certificate revocation list， CRL）的LDAP或者HTTP URI地址。每一张证书都至少需要包括CRL或者OCSP吊销信息。
• 颁发机构信息访问( Authority Information Access):该扩展表明如何访问签发CA提供的额外信息和服务，例如：OCSP服务。还有一些证书包含了签发CA的URI地址，有了这个地址，即便服务器返回的证书链中缺
  少了签发CA的证书，客户端也可以通过下载签发CA重新构建证书链。
• 使用者密钥标识符(Subject Key Identifier):
  该扩展可以用来识别包含特别公钥的证书，一般建议使用公钥本身来
  建立这个标识符（例如通过散列）。所有的CA证书都必须包含这个扩展，并且它的值要与
  CA所签发出来的证书上的授权密钥标识符的值一样。
• 授权密钥标识符(Authority Key Identifier):该扩展是签发此证书CA的唯一标识符，通常用于在构建证书链时找到颁发者
  的证书。
• 其他扩展：除了上述的扩展外，还有增量CRL分发点、禁止任意策略、颁
  发者可选名称、策略限制、策略映射、使用者目录属性、使用者信息访问等

2.3 证书的格式

证书可以以各种格式进行存储，常见的格式如下所示。

• DER：Binary (DER) certificate
  包含原始格式的X.509证书，使用DER ASN.1编码。

• PEM：ASCII (PEM) certificate(s)
  包含base64编码过的DER证书，它们以-----BEGIN CERTIFICATE-----开头，以-----END
  CERTIFICATE-----结尾。虽然有些程序可以允许多个证书存在一个文件中，但是一般来说
  一个文件只有一张证书。由于该种格式的证书容易查看，所以比较常用。

• PKCS：PKCS#7 certificate(s)
  RFC 2315定义的一种比较复杂的格式，设计的目的是用于签名和加密数据的传输。一般
  常见的是.p7b和.p7c扩展名的文件，并且文件里面可以包括所需的整个证书链。 Java的密
  钥管理工具支持这种格式。

Key也可以以各种格式进行存储，常见的格式如下所示。

• DER：Binary (DER) key
  包含DER ASN.1编码后的私钥的原始格式。 OpenSSL使用他自己传统的方式创建密钥
  （ SSLeay）格式。还有另外一种不常使用的格式叫作PKCS#8（ RFC 5208定义的）。 OpenSSL
  可以使用pkcs8命令进行PKCS#8格式的转换。

• ASCII (PEM) key
  包括base64编码后的DER密钥和一些元数据信息（例如密码的保存算法）。

• PKCS#12 (PFX) key and certificate(s)
  一种可以用来保存服务器私钥和整个证书链的复杂格式，一般以.p12和.pfx扩展名结尾。
  这类格式常见于Microsoft的产品，但是也用于客户端证书。虽然很久以前PFX表示
  PKCS#12之前的版本，现在PFX常被用作PKCS#12的代名词，不过你已经很难遇到老版

2.4 证书链

在大多数情况下，仅仅有最终实体证书是无法进行有效性验证的，所以在实践中，服务器需
要提供证书链才能一步步地最终验证到可信根证书，证书链的结构如下图：

证书链主要有下面几个注意事项：

• 保证根证书安全：根证书非常重要，如果根CA的私钥被泄露，那么就可以签发任意域名的虚假证书。另外
  如果根CA会被吊销掉，所有使用这个CA签发出来的证书的网站都会无法访问。Baseline Requirements限制所有的根证书密钥只能由人手动执行命令
• 交叉证书：想将新的CA投入使用，必须基于已经广泛内置的CA对他们的根密钥进
  行签名。等老的设备都淘汰掉了，新的CA才能最终独立使用。
• 二级CA：根CA会将它的操作分散给很多二级CA。例如不同的二级CA用于签发不同的证书类型。二级CA一般都是在线的，而且使用自动化系统签发证书。
• 委派：还有一些情况是CA希望给外部其他组织签发一个二级CA。例如一家大的公司可能希望有自己可控的二级CA。候CA就会从技术上限制这个二级CA只能签发某些域名；

理论上服务器一次只能提供一条证书链，而实际上可能存在多条可信路径，例如交叉证书。
多路径以及证书配置的问题是很多安全问题的根源。历史上有很多验证库在验证签发CA属于哪个根CA这类简单问题上都出现过问题。

2.5 证书吊销

当出现私钥泄露或者不再需要使用的时候，我们就需要吊销证书,方式主要有以下两种：

• 证书吊销列表（ certificate revocation list， CRL）：是一组未过期、但是却已经被吊销的证书序列号列表， CA维护了一个或多个这样的列表。每一张证书都需要在CRL分发点（ CRL
  distribution point）扩展中包含对应的CRL地址。CRL最大的问题在于它越来越大，实时查
  询起来会非常慢。
• 在线证书状态协议（ online certificate status protocol， OCSP）：允许信赖方获得一张证书的
  吊销信息。 OCSP程序的地址编码在颁发机构
  信息访问（ authority information access， AIA）证书扩展中。 OCSP支持实时查询并且解决了CRL最大的缺点，但是并没有解决所有的吊销问题：因为OCSP的使用带来了性能、隐私方面的问题和新的漏洞。其中一部分问题可以通过OCSP stapling技术来解决，它允许服务器在TLS握手的过程中直接嵌入OCSP响应

3. 存在问题与解决方案

人无完人，PKI体系虽然很强大，但也存在一些问题，问题如下：

1. 任何CA都可以在未经域名所有者授权的情况下签发该域名的证书
2. 信赖方维护了包含一定数量CA证书的根证书库，这样CA要么是完全可信，要么完全不可信，没有中间情况。
3. DV证书是通过不安全的WHOIS协议获取域名信息，然后基于域名所有者信息来签发证书
   的。此外，验证过程经常是用邮件沟通，本身也是不安全的
4. 吊销可能不生效
5. 很多库和应用完全绕过了验证过程，例如：浏览器虽然会检测证书，但是当遇到无效证书时，它们却又允许用户忽略警告信息

下述方案可以解决上面的部分问题：

• 公钥钉扎：公钥钉扎解决了当前PKI生态系统里面最大的弱点，也就是任何CA都可以在未经域名拥有者同意的情况下给任意域名签发证书。有了钉扎之后，网站的拥有者可以选择（钉）一个或者多个他们信任的CA，创造他们自己单独的、比全球生态系统小很多的可信生态
  系统。
• DNSSEC：DNSSEC是在DNS的基础上扩展了完整性检查的一组新协议。有了DNSSEC，域名可以与一组密钥关联起来，这一组密钥用于给对应DNS区进行签名。 DANE是DNSSEC和TLS验
  证之间的桥梁。虽然DANE也可以用来做钉子，但是它最令人感兴趣的能力是完全绕过公
  共CA，如果你信任DNS，就可以用它做TLS验证。
• 证书透明度：证书透明度（ certificate transparency， CT） 是一套审计和监控公开证书的框架。 CA将他们签发的每一张证书都提交到公开证书日志里面，然后获得一个此次已提交的加密证明。任何人都可以监控CA签发的每一张新证书。例如域名拥有者可以监控每一张签发了他们
  域名的证书。这个想法如果实现的话，那么虚假证书就可以快速地被发现。上述例子中百度的证书里就已经包含了CT的信息