技术问答 | GlobalSign 10.13 Certificate Issues 分析【转】
据悉10月13日知名数字证书颁发机构（CA）GlobalSign的OSCP 故障致使大量网站证书被吊销，直接导致了国内天猫和京东的部分用户在 10.13 号晚上躺枪， 打开天猫和京东时提示「NET::ERR_CERT_REVOKED」。
本文将从 GlobalSign 10.13 的证书吊销事件开始，逐步延伸到 CA 处的 CRL 、OCSP 分发结构，并大概介绍下几个主流浏览器及 Windows 7 、macOS 系统中的 OCSP Response 缓存的保存和管理。
为了更好理解这个 Case ，先解释几个名词的意思：
PKI： Public Key Infrastructure 即公钥基础设施。
Subject Name : 证书中的 Subject Name 。
Serial Number ：证书的 Serial Number 。
CRL：Certificate Revocation List 证书吊销列表 RFC 5280 https://tools.ietf.org/html/rfc5280 ，需要用户下载对应证书的 CRL 文件。
OCSP ：Online Certificate Status Protocol 在线证书状态协议是维护服务器和其它网络资源安全性的两种普遍模式之一。OCSP克服了证书注销列表（CRL）的主要缺陷：必须经常在客户端下载以确保列表的更新。当用户试图访问一个服务器时，在线证书状态协议发送一个对于证书状态信息的请求。服务器回复一个「有效(GOOD)」、「过期(REVOKED)」或「未知(UNKNOWN)」的响应。协议规定了服务器和客户端应用程序的通讯语法。在线证书状态协议给了用户的到期的证书一个宽限期，这样他们就可以在更新以前的一段时间内继续访问服务器(百度百科)。
Cross Certification：交叉认证,通过交叉认证后的 CA，可以相互信任对方的 PKI，常用在两个 CA 之间。
10.7 号 GlobalSign 吊销了一个在 Root CA R2 签发的 Serial Number 为 0400000000011256ad5fb2 的 CA 中间证书，并签发了一个 CRL ，0400000000011256ad5fb2 和 0400000000011256ad5fb2 是 Cross Certification，而 GlobalSign 的 Root CA R1 也和 0400000000011256ad5fb2 Cross Certification （使用了相同的 Public Key 和 Subject Name） ，到 10.13 号 Root CA R2 更新 OCSP 时包含了 0400000000011256ad5fb2 ，也最终导致了 Root CA R1 被「吊销」，也直接导致了 Root CA R1 签发的一系列中间证书被「吊销」。
主要受影响的中间证书有： DomainSSL 、 AlphaSSL 等。
GlobalSign 的处理流程主要为: 定位到问题后，清除了 OCSP Database 中交叉签名的证书，Flush Cache , 推送 Cache 到全球 CDN 。但是终端用户的机器的上的缓存，需要用户自己手动去清理，Chrome 和 Safari 由于使用了系统维护的 OCSP Response Cache，macOS 下由 ocspd 进程维护，ocspd 将 OCSP Response 保存在 Sqlite 中，所以手动清除的方式为： sqlite3 ~/Library/Keychains/*/ocspcache.sqlite3 ‘DELETE FROM ocsp;’ ， Windows 下清除 OCSP Cache 和 CRL 缓存 : certutil -urlcache * delete 。
如果有用户在 Server 端做了 OCSP Stapling ，以 NGINX 为例，如果是用 ssl_stapling_responder 指令去从 CA 拉取后缓存到 Server 端的话，则还需要清空下 NGINX 处 OCSP Response 的 Cache 。
在 PKI 体系中，证书的验证可以在本地完成，但是证书的是否有效，则需要和签发该证书的 CA 通信, 终端用户（End User ）和 CA 之间有 CRL， OCSP 两种协议去验证证书是否有效。
以 GlobalSign 为例，大概说下 CRL 和 OCSP 的分发。CRL Publish 后， GlobalSign 会将 CRL 分发到全球 CDN， GlobalSign 的 CRL CDN 用的是 Cloudflare 的服务
GlobalSign OCSP 的 OCSP CDN 服务也是 CloudFlare （国内是百度云加速节点），下图为 OCSP Request 和 Response 的数据流 ：
GlobalSign 将 OCSP Response 使用 HTTP 协议走 CDN 分发， 终端用户发起 OCSP Request 时，先到 CDN ，没有命中则 CDN 发起 OCSP Request ，经由 OCSP Responder Load Balancers 到 Delegate OCSP Responders 处理。
Windows 和 macOS 都使用 Pre-Fetching 机制去缓存 OCSP 和 CRL ， Windows 的 Pre-Fetching 使用 cached ETag 和 Cache-Control:max-age 的值决定是否更新 OCSP 和 CRL 缓存， CryptoAPI依据 ThisUpdate 、NextPublish、NextUpdate 的时间决定是否 Pre-Fetch 。
Windows 中的 CRL 和 OCSP Cache 保存在 C:\Users\username\AppData\LocalLow\ Microsoft\CryptnetUrlCache 和 C:\Windows\System32\config\ systemprofile\AppData\LocalLow\ Microsoft\CryptnetUrlCache 中,可以通过 certutil 工具管理：
macOS 中则是 Security.framework 对 OCSPD 进程的 RPC 调用，在证书的验证阶段 Security.framework 通过私有的 RPC 接口，缓存 OCSP Response 到 sqlite3 中，即上文中提到的 ~/Library/Keychains/*/ocspcache.sqlite3 中的 ocsp 和 responses 两个表中：
本文主要介绍 GlobalSign 10.13 的证书吊销 Case、 CA 处的 CRL 、OCSP 分发结构、几个主流浏览器和 Windows 7 、macOS 系统中的 OCSP 缓存，细节描述的并不是很多，有兴趣的同学可以继续阅读下相关 RFC 。
问题：在和开启 OCSP Stapling 的 Server 端进行 TLS Handshake 时， 比如百度：
OCSP Response Data 中的 This Update 和 Next Update 之间差 7 天, 这个时间是谁决定的？为什么？
获奖方式：在精选留言中，将挑选出3名作者最满意的答案送出滴滴公仔。
此条目发表在
未分类,
经验技术分类目录。将
固定链接加入收藏夹。
