HTTPS学习笔记:(3)一文彻底了解PKI与证书

网络协议 专栏收录该内容
4 篇文章 1 订阅

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的信息
  • 1
    点赞
  • 0
    评论
  • 2
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值