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

拼搏现实的明天。 2023-06-21 14:30 388阅读 0赞

# 1. PKI #

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

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

# 2. 证书 #

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

## 2.1 证书的分类 ##

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

1.  域名验证型（DV）
    
     *  只验证网站域名所有权
     *  仅能加密通信内容，不能向用户证明网站的真实身份
     *  适合无身份认证需求的网站，如larave\_china等
2.  组织验证型（OV）
    
     *  需验证域名所有权和所属单位的真实身份。
     *  不仅能加密通信内容，还能向用户证明网站的真实性
     *  适应电子商务，企业等网站使用，如亚马逊商城
3.  扩展验证型（EV）
    
     *  严格的身份验证，最高安全级别
     *  提供通信内容加密与网站身份证明，浏览器状态显示单位名称。
     *  适合金融证券，银行等网站使用，比如工商银行

## 2.2 证书结构 ##

从浏览器以及censys(https://censys.io/certificates) 都可以清洗的看到证书的信息：  
浏览器上部分证书内容如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 1]

在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 证书链 ##

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

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

*  保证根证书安全：根证书非常重要，如果根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的信息

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191213115721751.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191213115741679.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191213120015435.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bjc1NDU1MjY=,size_16,color_FFFFFF,t_70