HTTPS:04---证书与公钥基础设施（PKI）

前言：

• 有了公开密钥算法之后，我们就可以通过他人的公开密钥与其安全通信，但是还有一些悬而未决的问题：如何与那些从未谋面的人进行沟通？如何存储和吊销密钥？最重要的是，如何让现 实世界中数以百万计的服务器、几十亿人和设备之间安全通信？这个问题非常的复杂，而公钥基础设施（public key infrastructure，PKI）就是为解决此问题而建立的

一、公钥基础设施（PKI）

• PKI就是互联网公钥基础设施
• 实际上PKI的含义更宽泛，因为其原本是 为了别的用途而开发的。因此更准确的说法是，由PKIX工作组为适应PKI在互联网上的使用而提 出的互联网公钥基础设施（Internet PKI）；另外一个最近常被用到的词是Web PKI，主要关注在浏 览器上如何使用和验证证书

PKI模型：

• 订阅人：订阅人（或者说最终实体）是指那些需要证书来提供安全服务的团体
• 登记机构：登记机构（registration authority，RA）主要是完成一些证书签发的相关管理工作。例如， RA会首先对用户进行必要的身份验证，然后才会去找CA签发证书。在某些情况下，当 CA希望在用户附近建立一个分支机构时（例如在不同的国家建立当地登记中心），我们 也称RA为本地登记机构（local registration authority，LRA）。实际上，很多CA也执行RA 的职责。
• 证书颁发机构：证书颁发机构（certification authority，CA）是指我们都信任的证书颁发机构，它会在确 认申请用户的身份之后签发证书。同时CA会在线提供其所签发证书的最新吊销信息，这 样信赖方就可以验证证书是否仍然有效
• 信赖方：信赖方（relying party）是指那些证书使用者。技术上来说，一般是指那些执行证书验证 的网页浏览器、其他程序以及操作系统。他们是通过维护根可信证书库来执行验证的， 这些证书库包含某些CA的最终可信证书（信任密钥，trust anchor）。更广泛地说，信赖方 是指那些需要通过证书在互联网上进行安全通信的最终用户

二、PKI标准

X.509

• 互联网公钥基础设施可以追溯到X.509，它是一种公钥基础设施的国际标准，最初是为了支 持X.500而设计的
• X.500是电子目录服务的标准，但是从来没有被广泛使用过
• X.509经PKIX工 作组的改造，适合在互联网上使用

PKIX工作组：

• PKIX工作组成立于1995年秋天，目标是建立支持基于X.509公钥基础设施的互联网 标准。最开始PKIX主要是分析CCITT（之后是ITU-T）的X.509标准，不久之后，PKIX 抛弃了ITU-T的工作，重新开始建立满足互联网需求的基于X.509的公钥基础设施。随着 时间的流逝，这项工作成为了PKIX的工作重点，举个例子，大多数PKIX提交的RFC不 再是ITU-T X.509文档的描述了
• PKIX工作组产出的最重要的文档是RFC 5280，它描述了证书格式、可信证书链的建立，以 及证书吊销列表（CRL）的格式。PKIX工作组在2013年10月结束了自己的使命

CBA论坛

• CA/Browser论坛（CAB论坛）是由证书颁发机构、浏览器厂商以及其他有相关权益的团体自 发形成的组织，目标是建立和推行证书颁发和处理的标准。一开始，CAB论坛是为了确定增强 型证书（EV证书）的颁发标准而创建的，在2007年EV证书诞生了。CAB论坛最开始只是一些 松散的组织，但是随后他们改变了关注的焦点并且在2012年改组。同年，CAB论坛发布了Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates（《公共可信证书的颁 发和管理基本要求》），简称为Baseline Requirements。
• CAB论坛虽然只列了大约40个证书颁发机构，但是Baseline Requirements适用于所有的证书颁发机构；这份文件被纳入到针对证书颁发机构的WebTrust审计程序中①，而有些根证书库运营 商（比如Mozilla）就明确要求CA必须符合这份标准

IETF’s Web PKI工作组

• 另外一个相关组织是2012年9月份成立的IETF’s Web PKI工作组，目的是描述PKI在Web上如 何真正工作起来。这个组织的目的是为Web PKI信任模型、吊销实践、证书中各字段和扩展的用 法、证书吊销列表和OCSP响应制定参考文献

三、证书

• 证书是一个包含公钥、订阅人相关信息以及证书颁发者数字签名的数字文件，也就是一个让 我们可以交换、存储和使用公钥的壳。因此，证书成为了整个PKI体系的基础组成元素

证书基本字段

• 版本：证书一共有3个版本号，分别用0、1、2编码表示版本1、版本2和版本3。版本1只支持简 单的字段，版本2增加了两个标识符（新增的字段），而版本3则增加了扩展功能。现在大 部分的证书都采用版本3的格式。
• 序列号：在一开始，序列号只要是正整数即可，是每个CA用来唯一标识其所签发的证书。但是在出 现了针对证书签名的预选前缀攻击之后，序列号增加了更多的要求来防止此类攻击；现在序列号需要是无序的（无法被预测）而且至少包括20位的熵
• 签名算法：这个字段指明证书签名所用的算法，需要放到证书里面，这样才能被证书签名保护
• 颁发者 颁发者（issuer）字段包括了证书颁发者的可分辨名称（distinguished name，DN），这个 字段比较复杂，根据不同的实体会包含许多部分。举例来说，Verisign根证书的可分辨名 称是/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority；它 包括了国家、组织和组织单位三个部分
• 有效期：证书的有效期包括开始日期和结束日期，在这段时间内证书是有效的
• 使用者：使用者是实体的可分辨名称，和公钥一起用于证书的签发。在自签名证书里，使用者 （subject）和颁发者（issuer）字段的可分辨名称是一样的。在最开始，可分辨名称里面的 公用名（common name，CN）主要用于服务器主机名（例如/CN=www.example.com用于 www.example.com域名的证书），但是如何为一个证书匹配多个主机名就变得比较麻烦了。 如今，使用者字段已经废弃，转而使用使用者可选名称扩展
• 公钥：这个字段包含了公钥，以使用者公钥信息（subject public-key info）结构呈现（主要是算 法ID，可选参数以及公钥本身）。公钥算法在RFC 3279里面有具体说明

证书扩展字段

为了让原本死板的证书格式变得更加灵活，版本3引入了证书扩展。每一个扩展都包括唯一 的对象标识符（object identifier，OID）、关键扩展标识器以及ASN.1格式的值。如果将某个扩展 设置为关键扩展，那么客户端必须能够解析和处理这个扩展，否则就应该拒绝整张证书

• 使用者可选名称：原本使用者证书字段（更准确地说是其中的通用名部分）是用来将身份信息和公钥绑定 在一起的。而在实际使用的时候发现使用者字段不够灵活，只能支持与一个主机名进行 绑定，无法同时处理多个身份信息。使用者可选名称扩展就是为了替换使用者字段，它 支持通过DNS名称、IP地址和URI来将多个身份绑定在一起
• 名称约束：名称约束扩展可以限制CA签发证书的对象，这样命名空间就在可控范围内。这个功能非 常有用，例如，它允许一个组织可以拥有一个二级CA，而这个CA只能签发这个公司所拥 有的那些域名下的证书。有了这个限制，这类CA就不会影响整个生态系统了（例如，CA 不能签发任意网站的证书）。 RFC 5280要求将这个扩展设置为关键扩展，但是实际情况是， 大部分CA都将其设置为非关键扩展，而Baseline Requirements也明确表示允许这么处理。 主要原因是有一些产品无法解析名称限制这个扩展，如果标记为关键扩展，就会导致这 些产品拒绝此类证书
• 基础约束：基础约束扩展用来表明证书是否为CA证书，同时通过路径长度（path length）约束字段， 来限制二级CA证书路径的深度（例如限制CA证书是否可以签发更深一层的CA证书以及 能签发多少层）。理论上，所有的CA证书都必须包含这个扩展；而实际情况是，有一些使 用版本1协议的根证书还在使用中，它们是没有任何扩展功能的
• 密钥用法：该扩展定义了证书中密钥可以使用的场景，这些场景已经定义好了，可以通过设置来让 证书支持某个场景。例如CA证书一般都设置了证书签名者（certificate signer）和CRL签 名者（CRL signer）
• 扩展密钥用法：为了更加灵活地支持和限制公钥的使用场景，该扩展可以通过OID支持更多的场景。例如 最终实体证书一般都拥有id-kp-serverAuth和id-kp-clientAuth两个OID，代码签名证书 使用id-kp-codeSigning OID等。 虽然RFC 5280表明扩展密钥用法（extended key usage，EKU）只能用在最终实体证书上， 但在实际中我们会看到中间CA也会带上这个扩展，从而让它签发出来的证书也带上这个 限制。Baseline Requirements还特别要求在使用EKU限制中间CA的同时还应当考虑使用名称限制。
• 证书策略：该扩展包含了一个或多个策略，每个策略都包括一个OID和可选限定符（qualifier）。限定 符一般包括一个URI，从这个URI可以获得完整的策略说明。Baseline Requirements要求每 一张最终实体证书需要包括至少一条策略信息，来表明该证书是在何种条款下签发的。 另外这个扩展还能表明证书的验证类型
• CRL分发点：该扩展用来确定证书吊销列表（certificate revocation list，CRL）的LDAP或者HTTP URI 地址。按照Baseline Requirements，每一张证书都至少需要包括CRL或者OCSP吊销信息。
• 颁发机构信息访问：颁发机构信息访问扩展表明如何访问签发CA提供的额外信息和服务，其中之一就是OCSP 响应程序的HTTP URI地址。信赖方可以使用这个服务来实时检测证书的吊销信息。另外 还有一些证书包含了签发CA的URI地址，有了这个地址，即便服务器返回的证书链中缺 少了签发CA的证书，客户端也可以通过下载签发CA重新构建证书链。
• 使用者密钥标识符：该扩展包含了唯一的值，可以用来识别包含特别公钥的证书，一般建议使用公钥本身来 建立这个标识符（例如通过散列）。所有的CA证书都必须包含这个扩展，并且它的值要与 CA所签发出来的证书上的授权密钥标识符的值一样
• 授权密钥标识符：这个扩展的内容是签发此证书的CA的唯一标识符，通常用于在构建证书链时找到颁发者 的证书

RFC 5280还定义了几个很少使用到的扩展，它们分别是增量CRL分发点、禁止任意策略、颁 发者可选名称、策略限制、策略映射、使用者目录属性、使用者信息访问

常用的证书协议：

• x509v3：IETF的证书标准

• x.500：目录的标准

• SCEP：简单证书申请协议，用http来进行申请，数据有PKCS#7封装，数据其实格式也是PKCS#10的

• PKCS#7：是封装数据的标准，可以放置证书和一些请求信息

• PKCS#10：用于离线证书申请的证书申请的数据格式，注意数据包是使用PKCS#7封装这个数据

• PKCS#12：用于一个单一文件中交换公共和私有对象，就是公钥，私钥和证书，这些信息进行打包，加密放在存储目录中，CISCO放在NVRAM中，用户可以导出，以防证书服务器挂掉可以进行相应恢复。思科是.p12,微软是.pfx

四、证书链

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

• 根CA证书：用来签发中间CA证书
• 中间CA证书：用来签发最终实体证书（客户端证书、服务端证书）
• 最终实体证书：客户端证书、服务端证书

证书链的一些术语：

• 保证根证书安全：根CA不仅对拥有它的组织很重要，对整个生态来说同样至关重要。首先是它有巨大的经 济价值，因为很多根证书库已经不再更新了，所以以前那些已经被广泛使用的根CA是不 可替代的。再者，如果根CA的私钥被泄露，那么就可以签发任意域名的虚假证书。另外 如果根CA会被吊销掉，所有使用这个CA签发出来的证书的网站都会无法访问。 现在仍然还有很多CA直接使用他们的根证书直接签发最终实体证书，这其实是非常危险 的。Baseline Requirements限制所有的根证书密钥只能由人手动执行命令（自动化是不允许的），也就是说根证书密钥必须离线保存。虽然还有很多依旧在使用的旧系统有这个漏 洞，但是直接由根证书签发最终实体证书是不允许的
• 交叉证书：交叉证书是可以让新的CA立即投入运营的唯一方式。因为想要在短期内让新的根证书部 署得足够广泛是不可能的，所以新的CA都会找已经进行广泛内置的CA对他们的根密钥进 行签名。随着时间的流逝，那些老的设备会逐渐淘汰掉，新的CA才能最终独立使用
• 划分：CA在将它的操作分散给很多二级CA的同时有可能会带来更多的风险。例如不同的二级 CA用于签发不同的证书类型，或者由不同的业务部门使用。与根证书不同的是，二级CA 一般都是在线的，而且使用自动化系统签发证书。
• 委派：还有一些情况是CA希望给外部其他组织签发一个二级CA。例如一家大的公司可能希望可 以自己签发它所拥有的那些域名的证书（这种方式通常比去维护私有CA，并确保所有设 备都内置这个CA来说成本更低）。有时候一些组织希望能够完全保管这个二级CA，这时 候CA就会从技术上限制这个二级CA只能签发某些域名；其他情况下CA依旧可以控制二 级CA签发出来的证书

• 服务器一次只能提供一条证书链，而实际上可能存在多条可信路径。以交叉证书为例，一条 可信路径可以一直到CA的主要根证书，另外一条则是到可选根证书上。CA有时候会为同样的密 钥签发多张证书，例如现在最常使用的签名算法是SHA1，因为安全原因正在逐步迁移到SHA256， CA可以使用同样的密钥签发出不同签名的新证书。如果信赖方恰好有两张这样的证书，那么就 可以构建出两条不同的可信路径
• 路径的建立让整个事情变复杂了，而且导致了很多问题。服务器必须提供完整并且有效的证书链，但是因为人员的疏忽或者各种各样的配置问题，导致证书链的配置总是有问题（例如需要 在不同的地方配置服务器证书和证书链剩余的部分）。根据SSL Pulse的数据，大概有5.9%的服务 器配置的证书链是不完整的
• 另外，因为标准的模糊、不完整以及相互矛盾，客户端在建立和验证路径上不可避免地出现 了很多安全问题。历史上有很多验证库在验证签发CA属于哪个根CA这类简单问题上都出现过问 题。如今最常使用的那些库并不是从一开始就安全的，也是经历过各种问题，打上了各种补丁后才慢慢经受住了实践的考验

五、信赖方（系统根证书库）

• 信赖方为了能够验证证书，必须收集信任的所有根CA证书。大多数的操作系统都提供一个根证书库，从而在一开始启动的时候就能够建立信任。几乎所有的软件开发者都重用了底层操作系统提供的根证书库，唯一的例外是Mozilla，为了保证不同平台的兼容性，它维护了自己的根证书库

• Apple Apple：维护的根证书库主要是给iOS和OS X平台使用，如果某个CA希望加入到Apple的根 证书库里面的话，就需要通过权威机构审计并且对Apple的客户有商业价值
• Chrome：在Linux上，Chrome使用Mozilla的根证书库（通过NSS网络库），除此之外Chrome都是依 赖操作系统提供的证书库。即便如此，Chrome在底层设施的基础上还额外增加了很多策 略。举例来说：(1) Chrome增加了根证书黑名单； (2) 增加了能够签发EV证书的CA列表； (3) 要求所有EV证书从2015年2月开始，必须支持证书透明度
• Microsoft Microsoft：维护的根证书库主要是给Windows桌面版、服务器版以及移动手机平台使用。同样，如果要加入，需要至少一年的审计并且提供一份能够为Microsoft的用户群带来商业价 值的说明
• Mozilla：Mozilla为自己的产品维护了一个公开透明的根证书库 并且大部分Linux版本都使用Mozilla的根证书库。在mozilla.dev.security.policy列表和Mozilla的bug跟踪系统上经常 会有一些针对制定策略的热门讨论话题

所有的根证书库都要求CA通过专门为证书颁发机构设计的独立审计。要签发DV和OV证书， 必须通过下面至少一项审计：

• 针对证书颁发机构的WebTrust审计
• ETSI TS 101 456
• ETSI TS 102 042
• ISO 21188:2006

要想签发EV证书，还必须通过由WebTrust运营的EV证书审计程序

六、证书颁发机构（CA）

• 证书颁发机构（certification authority，CA）是当前互联网信任模型最重要的部分，他们可以 签发任何域名的证书，所以是非常权威的

组建一个公开CA的步骤

• ①建立CA组织

a. 在PKI和CA的运营上非常专业

b. 需要设计一个健壮、安全、隔离的网络，以便在支持商业运作的同时，能够保护根证 书以及二级证书密钥的安全

c. 支持证书生命周期管理流程

d. 符合Baseline Requirements的规定

e. 符合EV SSL证书指导规范

f. 提供全球化的CRL和OCSP基础服务

• ②符合当地法律，这意味着可能需要按照当地的法规要求获取相应许可证
• ③通过根证书库认可的那些审计
• ④将你的根证书内置到尽可能多的设备、软件中
• ⑤找个已经内置的CA完成交叉证书，之后就可以开始运作了

• 在很长一段时间里，那些很早就进入这个市场的证书机构可以非常容易地出售证书。但是因为竞争越来越激烈，DV证书的价格下降得非常多，所以仅靠卖DV证书已经越来越难挣钱了。此 外，如果DNSSEC和DANE得到广泛使用，DV证书的日子也就到头了。因此现在CA正在转向更 小众、但可能更有赚头的EV证书市场和相关服务

七、证书的签发与生命周期

• 证书的生命周期在订阅人准备证书签名申请（certificate signing request，CSR）文件，并将 它提交给所选CA的时候就开始了
• CSR文件：CSR文件的主要目的是携带公钥信息，并且证明订阅人拥有 对应的私钥（通过签名来证明）。CSR还设计携带额外的元数据，但实际中并非所有的都用到了
• CA一般都会覆盖CSR文件的一些内容并且将其他信息内置到证书里面

签发前，CA会根据不同类型的证书申请，执行不同的验证流程：

• 域名验证：域名验证（domain validated，DV）证书需要CA验证订阅人对域名的所有权之后才能进行 签发。大多数情况下CA会发送一封确认邮件给域名的管理邮箱，管理员通过之后（按照 邮件里面的步骤和链接）CA就会签发证书。如果无法通过邮件确认，那么CA通过别的通 信手段（例如电话或者邮寄信件）或者合理的方式证明订阅人对域名的所有权之后就可 以签发证书。签发IP地址证书的步骤也是类似的
• 组织验证：组织验证（organization validated，OV）证书会对身份和真实性进行验证。直到采用了 Baseline Requirements之后，OV证书的验证流程才标准化起来，但是在如何签发OV证书 以及如何将这些信息编码到证书中等方面，依旧存在很多前后不一致的情况。
• 扩展验证：扩展验证（extended validation，EV）证书以更加严格的要求验证身份和真实性。它是为 了解决OV证书缺乏的前后一致性而引入的，所以EV证书的验证流程非常详细，几乎不会 出现前后不一致的情况

DV证书的签发是全自动的，所以非常快，它的签发时间主要取决于DNS管理员确认邮件所 需的时间；而EV证书则相反，可能需要几天甚至几周才能拿到

• CA在验证成功之后就会签发证书。除了证书本身，CA还会提供所有的中间证书，从而构建 证书链到对应的根证书上，当然对一些主流的平台也会介绍如何进行配置
• 在证书有效期范围内，申请者可以在他们的生产环境中使用该证书。如果证书对应的私钥泄露了，那么就需要吊销证书。这个过程和证书的签发有点类似。有一种说法叫作补签证书，不过从技术角度看，不存在补签证书一说：如果一张证书被吊销了，那么就需要按照证书申请签发流 程换一张新证书

八、证书的吊销

• 吊销的场景：当出现私钥泄露或者不再需要使用的时候，我们就需要吊销证书
• 但是这里存在误用的风险。 吊销协议和流程的设计是为了确保证书是有效的，否则就需要将吊销情况通知信赖方

证书吊销的标准：

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

九、PKI的弱点

• 从严格的安全视角来看，互联网PKI存在许多大大小小的弱点，在本节中我会将它们列出来。 当然，在讨论这些弱点之前，我们需要先看看它的历史。在1995年，也就是安全Web刚刚兴起的 时候，互联网完全和现在不一样，而且也没有现在这么重要。在那个时候，我们需要加密协议才 能开办电子商务，才能赚钱。如今我们已经有了非常不错的电子商务，但是我们想要的更多。对 一些组织来说，加密真的是生死攸关
• 但是我们如今拥有的体系还是之前设计的，为的只是保证电子商务操作足够安全。从更宽泛 的概念上来讲，这个体系提供了我称为商业安全（commercial security）的保障。用相对很少的钱 就能达到这样的安全，它可以让网站跑起来更快，可以允许一些不安全的实践，而且几乎不影响 用户。它由那些追逐利润的CA厂商，以及只注重扩大市场份额的浏览器供应商所控制，而他们 从未将安全列入最高优先级。当然也不能完全归咎于他们，只有我们这些最终用户行动起来，提 出更多的安全需求，他们才会作出改变
• 仅有CA是无法成功的。每年，数百个CA会签发出几百万张证书来让整个世界正常运转， 错误率非常低。当然在安全上没有想象得那么美好，但是整个体系运转得还挺好。尽管如此， 还是有很多的订阅人因为要付费购买证书而对CA产生不满。他们不想掏钱，同时却又希望拥有 绝对的安全
• 事实上，人们是无法从当前这个不愿意破旧立新的生态体系中获得绝对安全的，无论这是好还是坏。尽管如此，问题正在得到修复，

一些缺陷：

• 未经域名所有者授权就可以签发证书

从原理上看，我们现在最大的问题是：任何CA都可以在未经域名所有者授权的情况下签 发该域名的证书。这里关键的问题就是当前没有任何技术手段可以确保CA不会产生疏漏 和安全过错。在只有几个CA的那个年代，这可能不是个问题，但是现在已经有了几百个 CA，这就成了一个大问题。如今整个PKI体系的安全级别等同于其中最薄弱的环节，而 现在我们已经有了很多潜在的薄弱环节。所有的CA都需要经过审计，但是审计的质量同 样存疑。例如一家荷兰的CA公司DigiNotar，虽然经过审计，但是在2011年，其整个安全 体系依旧被完全入侵

那么接下来的问题就是，我们能否信任CA可以做好他们自己的工作并且能够考虑公众利 益？我们应该允许哪些CA有权利在缺少监督的情况下签发证书？有时候我们有正当的理 由去担心这些CA会将他们的商业利益置于我们的安全需求之上。例如，TrustWave在2012 年承认签发了一个二级CA用于流量审查，它会给任意网站签发伪造的证书。①虽然 TrustWave是唯一公开承认签发这类证书的CA，但还有很多传言说这种情况并不少见。 很多人担心政府部门会滥用这个体系，伪造签发任意域名的证书。我们真的可以确定一 些CA后面没有政府的背景吗？即便真的没有，我们又如何确保他们不会被迫做政府要求 的事情？唯一无法确认的是，不知道政府在商业CA中渗透得有多深

• 缺少信任灵活度

还有一个理论上的问题是缺少信任灵活度。信赖方维护了包含一定数量CA证书的根证书 库，这样CA要么是完全可信，要么完全不可信，没有中间情况。理论上，信赖方是可以 从根证书库里移除CA的，但实际上，只有出现严重不称职或者安全泄露问题，或者CA 体量很小时，才会出现上面这种情况。一旦CA签发了大量的证书，就会出现大而不倒的 情况。

某些象征性的惩罚还是有可能的。例如，过去有信赖方吊销过某些不称职CA的EV证书权 限。另外一个想法（从未尝试过）就是，对于有过恶劣行为的CA，不再信任他们未来签 发的证书，只信任他们已经签发的证书。

• 弱域名验证

DV证书是通过不安全的WHOIS协议获取域名信息，然后基于域名所有者信息来签发证书 的。此外，验证过程经常是用邮件沟通，本身也是不安全的。如果攻击者劫持了域名或 者获得了关键邮箱的访问权限，那么要获得一张伪造的DV证书会非常容易。另外还可以 通过窃听CA端的网络来攻击CA的验证过程

• 吊销不生效

吊销不生效的情况比较普遍。我们发现在2011年有几个CA的吊销失效了。在每个案例中，信赖方不得不打补丁或者使用他们自有的黑名单通道来吊销错误签发的证书。

有两个原因说明这是有必要的。首先在每个系统之间传播吊销信息会有延迟。Baseline Requirements允许CRL和OCSP的信息有效期最多可以是10天（中间证书则是12个月）。也 就是说吊销信息的传播需要至少10天的时间。第二个问题是当前所有浏览器都已实现的 软失败（soft-fail）策略；它们会尝试获取吊销信息但会忽略所有的失败。主动网络攻击 者可以很容易地阻断OCSP请求，然后让其无限期地使用本已无效的证书。

浏览器厂商因此决定停止吊销检测。CRL首当其冲，紧接着是OCSP。目前的趋势是利用 专有的机制，先查询少数中间证书的可靠吊销信息，再查询其他的吊销信息。未来的解 决方法可能是提供一种新的吊销信息查询机制，但是该方法现在还毫无进展

• 证书警告让加密意图完全失效

互联网PKI（准确说是Web PKI）最大的失败可能是证书验证的松散实现。很多库和应用 完全绕过了验证过程。浏览器虽然会检测证书，但是当遇到无效证书时，它们却又允许 用户忽略呈现给它们的警告信息。根据一些统计估计，大概有30%~70%的用户会点击跳 过这些警告，这让我们的加密意图完全失效。最近，一种称为HTTP严格传输安全（HTTP strict transport security，HSTS）的新标准出现了，它要求所有实现它的浏览器用错误替换 警告，并且不允许忽略错误

十、根密钥泄露

• 攻击PKI最好的方法之一是直接对根证书下手
• 如果是政府部门，可以直接要求该国的CA交出他们的私钥。如果觉得这种行为存在争议或者非常危险，那么只要有一些预算（比如一百万美元左右）就可以自己创建一个新的CA品牌，并且将其根证书内置到所有的证书库里面。他们甚至可能觉得没有必要去好好运作一个CA以便进行掩饰，因为有很多根证书从来没有签发过最终实体证书
• 这种攻击互联网PKI的手段在之前的很多年都是行之有效的，但是从近两年开始，人们对整 个生态系统发生的事情越来越关注。浏览器建立了证书跟踪的插件，它们会在新证书出问题的时候警告用户。Google在非常流行的Chrome里面实现了公钥钉扎（public key pinning）。电子前线基 金会对他们的HTTPS Everywhere插件进行了扩展，增加了对根证书使用的监控
• 另外一种（在过去和现在都）不这么复杂的方式是打破现存的根证书和中间证书。如果你有权限访问中间证书对应的私钥，那么就可以签发任意的证书。为了最好的效果（尽可能不被发现）， 签发伪造证书的CA最好与真正的CA一样。很多站点，特别是那些大型站点，同一时间可能会运 营着多张证书。如果签发CA是一样的，那么要如何区分伪造证书和真实证书呢？
• 2003年（已经是10多年前的事了），Shamir和Tromer估计花费1000万美元特别建造的机器可以在1年内破解1024位的密钥（还需要额外的2000万美元的设计和开发费用）。按照那些可能已 经公开的伪造证书来计算，这对国家机构来说其实是非常廉价的。这些机构通常会花费几十亿美 元在有兴趣的项目上。2013年，Tromer估计成本下降到只要100万美元

• 从Tromer的估计来看，有理由相信所有1024位长度的密钥已经被不同国家的多个政府机构破解了。在某些情况下，有理由相信最终实体证书也被盯上了。例如Google在2013年把所有的1024 位证书都替换掉了
• 奇怪的是，既然知道了攻击弱证书的成本很低，但我们还在使用弱根证书。Mozilla计划在2013 年底移除这类根证书，但是因为可能会造成很大的影响，所以他们延期了。如果要跟踪他们的 进展，可以查看bug #881553。在写这本书的时候，也就是2015年7月份，Mozilla计划在2015年 末移除剩余的弱根证书

十一、PKI的改进

多年以来，我们看到了很多改变PKI的提案，特别是在2011年。好几家CA在那一年受到入侵， 让我们觉得整个互联网都要瓦解了。这里我会简单介绍一下这些提案，不过它们中的大部分还未最终确定。还有一些提案在宣布之后没有什么进展。唯一的例外是钉扎（pinning）和DANE，这些技术几乎可以在实际中使用

• 透视：透视首先在TLS验证过程中引入独立公证人的概念。由客户端推荐可信的公证人，而不 是直接单独对证书颁发机构资质的有效性作出决定。从不同的有利位置去访问同一个服 务器可以击败客户端附近发生的攻击。公证人可以对服务器进行一段时间的跟踪来击败 更高级别的攻击。透视在2008年启动，目前仍在运作
• 收敛：收敛是透视的一个分支，并且在某些实现方面有所提高。为增加隐私，发给公证人的请 求需要经过多个服务器，这样公证人只知道客户端的身份，但是不知道请求的内容。为 提高性能，站点证书会被缓存一段时间。在2011年收敛刚被提出的时候势头很猛，但是 从2013年开始就很少见有人提它了。最可能的原因是浏览器无法提供足够的API来支持想 要做信任决策的插件
• 公钥钉扎：公钥钉扎解决了当前PKI生态系统里面最大的弱点，也就是任何CA都可以在未经域名拥 有者同意的情况下给任意域名签发证书。有了钉扎之后，网站的拥有者可以选择（钉） 一个或者多个他们信任的CA，创造他们自己单独的、比全球生态系统小很多的可信生态 系统。公钥钉扎现在可以通过Chrome的专有机制实现，而HTTP公钥钉扎（public key pinning for HTTP）标准也在制定中
• DANE：DNSSEC是在DNS的基础上扩展了完整性检查的一组新协议。有了DNSSEC，域名可以与 一组密钥关联起来，这一组密钥用于给对应DNS区进行签名。DANE是DNSSEC和TLS验 证之间的桥梁。虽然DANE也可以用来做钉子，但是它最令人感兴趣的能力是完全绕过公 共CA，如果你信任DNS，就可以用它做TLS验证
• 主权密钥：主权密钥（Sovereign Keys）提案在现存的安全体系（包括CA和DNSSEC）中增加了更 多的安全保障。主要的思路是域名可以声明使用主权密钥，这会记录在公开的、可验证 的日志里面。声明之后，该域名的证书只能使用这个主权密钥进行签发才有效。它的问 题是没有相关条款规定如果主权密钥泄露了我们该怎么办，这样就让该提案有很大的风 险。主权密钥在2011年被提出，但是还处在构想阶段
• MECAI：CA是在一种公证人的概念上运行的体系，而互信CA基础设施 （mutually endorsing CA infrastructure，MECAI）则是这种公证人的一个变种。服务器处理所有的工作，然后将 最新的证人发送给客户端。这大部分的过程都发生在幕后以便增强隐私和提高性能。 MECAI在2011年被提出，但是还处在构想阶段
• 证书透明度：证书透明度（certificate transparency，CT）是一套审计和监控公开证书的框架。CA将他 们签发的每一张证书都提交到公开证书日志里面，然后获得一个此次已提交的加密证明。 任何人都可以监控CA签发的每一张新证书。例如域名拥有者可以监控每一张签发了他们 域名的证书。这个想法如果实现的话，那么虚假证书就可以快速地被发现。提交证明可以 通过不同的方法交付给客户端（最好是在证书本身内部），这样就能用来确认该证书已经 被公开了。从2015年2月开始，Chrome要求所有2015年之后签发的EV证书都有CT。Chrome 有一份白名单用来对那些在2015年1月份之前签发的EV证书进行识别，如果能证明该试点 项目成功，Chrome的开发者倾向于最后所有的证书都需要有CT
• TACK：证书密钥可信保证（trust assurances for certificate keys，TACK）①是钉扎的一个变种，用 来钉住服务器提供的签名密钥。引入一个长期的签名密钥意味着要做更多的工作，但是 可以独立于整个CA体系。这个提案的不同之处在于，它支持所有使用TLS进行保护的协 议，而不仅仅是HTTP。TACK于2012年提出，作者提供了一些主流平台的概念验证，不 过直到撰写本书之时，还没有任何客户端中提供官方支持

• 这些提案有希望得到实现吗？在2011年当大部分提案刚出来的时候，确实有很大的一股动力 试图改变现状。不过在之后实现的时候，人们才认识到问题的难度。我们很容易设计在大多数情 况下运转良好的系统，但是当遇到边界问题的时候，大部分系统都无法很好地工作。
• 基于公证人的提案所面临的问题是，浏览器的API才刚刚取得进展。这些提案致力于解决本 地攻击的问题，但是遇到了太多的警告。通过依赖多个外部系统来获得信任，这些提案会增加决 策难度（例如，如果不同公证人之间存在不一致，或者系统中来了一个流氓分子，rogue element）， 而且还引入了性能、可用性以及运行成本等多个问题。大型站点经常会给同一个域名部署多个证 书，特别是从不同的地理位置观察时。这会导致的一个假象是：不止一个公证人是正确的。
• 钉扎的提案看起来比较有希望。有了钉扎之后，站点所有人就可以选择相信谁，这样就可以 解决大量针对当前系统的攻击。Google在2011年部署了钉扎，使得DigiNotar CA被入侵的事情曝 光。他们的专有钉扎机制在这时候还侦测到几起别的问题。希望钉扎功能可以在不久的将来通过 一种标准化的机制对每个人都可用。
• DANE是唯一从实质上改变我们信任机制的提案，但它的成功取决于操作系统和浏览器对 DNSSEC的支持。浏览器供应商对这事暂时没什么激情，不过操作系统可能会最终实现。对于低 风险的业务，DANE是一个很好的方案，甚至可以完全替代DV证书。另外一方面，高风险的业 务对DNS的集中信任可能是一个潜在的问题；关键的问题在于无法避免政府的各种影响。现在支 持DANE的还很少，不过随着DNSSEC的发展肯定也会越来越多的。
• 考虑到Google的影响力，CT是非常有可能成功的，不过需要经过几年时间，等有了足够多 的部署，就会完全显现出效果。
• 总的来说，我们有两个方向可以并行地去做，它们会形成一个不同安全等级的多层系统。第 一个方向是改进当前系统。例如Mozilla通过它的根证书库的影响力对CA们进行施压，以保证他 们不会出现问题。事实上，CA承受了非常大的压力，导致在2012年CAB论坛的重组，并且确定 了Baseline Requirements。从2010年开始增加的监控和审计行为帮助发现了很多小问题（现在大部 分都解决了），而且继续对整个系统进行检查。最终，CT可能通过所有的公开证书存储库来实现 公共信任的完全透明化。
• 第二个方向是使高风险网站可以选择更高的安全性。互联网PKI在实践中遇到的最大问题可 能就是我们希望用一个系统解决所有人的问题。实际情况是，有很多的业务只需要简单的安全（低 成本、低付出），一小部分业务希望能够有足够的安全而且愿意为其进行改造。新的技术（例如 钉扎、HTTP严格传输安全、内容安全策略以及强制OCSP stapling）可以带来更高级别的安全。

附加：

 

• 根证书：一般是大型公司使用，由证书颁发机构（CA, Certificate Authority）颁发，具有权威性，被互联网承认

• 自签名证书：没有向证书颁发机构申请，自己生成的证书，因为是自己生成的不被互联网承认的，所以用浏览器访问服务端时会报安全提示，要求你手动安装证书

HTTPS中证书与公钥的交互过程：

• 客户端提前拥有服务端的证书，所以客户端有服务端的公钥，但是在SSL握手的时候服务端会将自己的证书发送给客户端，来验证客户端拥有的证书的有效性与一致性（如果不一致可能会警告等）
• 服务端没有提前没有客户端的证书，所以没有客户端的公钥，在SSL全流程握手的时候，服务端会向客户端索要证书

HTTPS中证书的单向认证与双向认证：

• 单向认证：客户端保存着服务端的证书，客户端访问服务端时需要经过服务端的证书认证（一般在Web服务器中使用）
• 双向认证：客户端与服务端都需要拥有对方的证书，并且需要经过双方的证书认证（一般在点对点安全通信、IOT设备中使用）

如果是单向认证的话，在SSL握手时，服务端就不会向客户端索要证书；如果是双向认证的话，服务端会向客户端索要证书

• 公钥：在证书中提供，所有人都知道
• 私钥：由随机数、Key值、公钥生成，只有自己知道

相关后缀名

• .key格式：私有的密钥

• .crt格式：证书文件，certificate的缩写

• .csr格式：证书签名请求（证书请求文件），含有公钥信息，certificate signing request的缩写

• .crl格式：证书吊销列表，Certificate Revocation List的缩写

• .pem格式：用于导出，导入证书时候的证书的格式，有证书开头，结尾的格式