手上有一个项目，基于安全、可信的关系，部署了 EVSSL，2年 3000+大洋。

某天，同事出差，给客户演示时，发现网站好久没打开（据说可能有7,8秒）

在现代网络高度发达的时代，这个速度是没法接受的。

今天突然看到一篇文章：

下面直接贴上：

SSL证书吊销检查

虽然证书吊销状态在不断变化，并且用户代理对证书吊销的行为差异很大，但作为服务器，要做的就是尽可能快地传递吊销信息。实际操作中转化为以下这些规则。

• 使用带OCSP信息的证书
  OCSP被设计用于提供实时查询，允许用户代理只请求访问网站的吊销信息。因此查询简短而快速（一个HTTP请求）。相比之下CRL是一个包含大量被吊销证书的列表。一些用户代理只有当OCSP信息不可用的时候才下载CRL，这种情况下浏览器与你的网站的通讯将被暂停，直到CRL下载完成。几十秒的延迟都不少见，尤其是通过慢速的网络连接时（想想移动设备）。
• 使用具有快速且可靠的OCSP响应程序的CA
  不同CA之间的OCSP响应程序性能也有所不同。缓慢和错误的OCSP响应程序会潜在地导致性能下降，这个现实被隐藏了很长一段时间。在你向CA提交之前先检查他们的历史OCSP响应程序。
  另一个选择CA的标准是它更新OCSP响应程序的速度。为了避免网站错误，你希望自己的证书一被颁发就加入到OCSP响应程序中。令人费解的是，有些CA对于新证书的OCSP更新拖延很久，这个期间OCSP响应程序都会返回错误。
• 部署OSCP stapling
  OCSP stapling是一种允许在TLS握手中包含吊销信息（整个OCSP响应）的协议功能。启用OCSP stapling之后，通过给予用户代理进行吊销检查的全部信息以带来更好的性能。OCSP stapling增加握手大约450字节，会让握手略微变慢，但可以省去用户代理通过独立的连接获取CA的OCSP响应程序来查询吊销信息。
  OCSP响应大小因签发CA的实际部署不同而不同。与最终实体证书（正在检查吊销的）具有相同CA签名的OCSP响应会比较简短。因为用户代理已经有签发CA的证书，OCSP响应可以只包含吊销状态和签名。
  一些CA喜欢使用不同的证书对OCSP响应进行签名。因为用户代理事先并不知道其他证书，CA必须将它们包含在每个OCSP响应里面。这会给OCSP响应略微增加超过1 KB的大小。

注意：当浏览器跳过吊销状态检查时，虽然会获得更好的性能，但也面临安全风险。EV证书始终检查吊销状态以提供更好的安全性。DV证书不总是检查吊销状态，可能有轻微的性能优势。这个问题可以通过OCSP stapling让两种类型的证书都有相同的性能来解决。

根据上述文章，如果服务器部署了EVSSL时，第一次打开总是检测证书吊销状态的。

而目前国际主流的SSL证书，OCSP服务器一般部署在国外，当网络连通性不好时，前面所述的可能需要等待7,8秒才打开，这个是完全有可能的。

又有一篇文章：

http://arstechnica.com/business/ ... cation-checking.ars

谷歌计划在未来数月内取消对网站SSL证书吊销检查，据公司一位研究人员称，该功能并不能使终端用户更加安全，因为包括Chrome在内的多数浏览器即使在SSL证书已经被吊销的情况下依旧会连接到有问题的站点。就好比汽车的安全带一样，虽然99%的时候都是有效的，可惜那时你并不需要它，滑稽的是当你真正需要的时候，安全带却忽然断开，起不了任何作用。

除了技术问题，用户体验也是一项原因，SSL证书吊销检查会增加页面载入时间，同时可能会侵犯隐私。据估算每次检查

平均需要要多增加300毫秒的时间，同时随着时间的推移，证书颁发机构会获取用户的IP地址和访问的站点。作为补充措
施，Chrome将会依靠本身的自动升级机制获取由于安全问题而遭移除的证书列表，这份列表将通过Google Bots 自动抓取

如果上述描述属实，chrome检查证书时，只检查证书链是否完整，证书签发时间是否有效。在这个情况下，

SSL 网站和 普通 http 网站访问速度没有太大的差别。

这样看来，那么下次部署 SSL 证书的时候，真的需要认真考虑是否部署 EVSSL 证书了，由于https访问速度和 http 影响不大，部署SSL还是非常有必要的。

本站已经全部采用https方式访问，多种途径，多浏览器测试，确实影响不大。（也许自我感觉良好）

如果是你，你又该如何打算呢？