知识点： 什么是CT（Certificate Transparency）证书透明？

“证书透明”，是谷歌公司提出来的改进SSL证书签发系统的一种先进的解决方案。在此之前，所有证书签发系统都是封闭 的、不透明的，谁也不知道CA系统何时为哪个域名签发了SSL证书。CT证书透明机制则加强了从CA的信任链一直向下延伸到每一台部署了SSL证书的服务器，浏览器从站点证书开始递归校验父证书，直至出现信任的根证书（根证书列表一般内置于操作系统，Firefox 则自己维护）。然而，受信任的 CA（证书颁发机构）有好几百个，他们成为整个网站身份认证过程中一个较大的攻击面。实际上，目前由于 CA 失误导致错误签发证书；以及个别 CA 出于某些目的（如监控加密流量）故意向第三方随意签发证书这两种情况时有发生。

无论是 CA 无意或有意签发出来的「非法证书」，都能通过目前的证书链校验机制的验证。这些 CA 签发的「非法证书」相比自签名的「无效证书」，更难被发现，即使被发现依靠现有机制也很难快速消除影响。另外，域名所有者的管理不善也可能导致域名配置被第三方控制，从而第三方能够向 CA 申请你网站的证书（特别是 DV 类型的证书）。这种情况，发现和处理同样很麻烦。而 Certificate Transparency 就是为了解决这些问题诞生的，它可以直译为证书透明度，由 Google 主导，并由 IETF 标准化为 RFC 6962。Certificate Transparency 的目标是提供一个开放的审计和监控系统，可以让任何域名所有者或者 CA 确定证书是否被错误签发或者被恶意使用，从而提高 HTTPS 网站的安全性。

Certificate Transparency 整套系统由三部分组成：1）Certificate Logs；2）Certificate Monitors；3）Certificate Auditors。完整的工作原理可以看官方文档：How Certificate Transparency Works。

简单说来，证书所有者或者 CA 都可以主动向 Certificate Logs 服务器提交证书，所有证书记录都会接受审计和监控。支持 CT 的浏览器（目前只有 Chrome）会根据 Certificate Logs 中证书状态，作出不同的反应。CT 不是要替换现有的 CA 设施，而是做为补充，使之更透明、更实时。

Certificate Logs 服务器由 Google 或 CA 部署，这个页面列（需要翻墙）举了目前已知的服务器。合法的证书提交到 CT Logs 服务器之后，服务器会返回 signed certificate timestamp（SCT），要启用 CT 就必须用到 SCT 信息

启用 CT 的三种方式
一：证书内嵌CA 先预签证书，并将证书提交到 CT Logs 服务器得到 SCT 信息，然后 CA 将 SCT 做为预签证书的扩展再次签名，这样就得到了一个含有 SCT 扩展的证书。

二:OCSP响应

CA 按照普通流程完成证书签发后，再将证书提交到 CT Logs 服务器得到 SCT，然后改造 OCSP（Online Certificate Status Protocol，在线证书状态协议）服务，将 SCT 信息包含到 OCSP 响应中。服务端启用 OCSP Stapling（OCSP 封套）后，就可以在证书链中包含证书的 OCSP 查询结果，其中就包含 SCT 信息。

三：通过 TLS 扩展

可以自己提交证书给 CT Logs 服务器，得到 SCT 并存起来。然后通过配置 Web Server，使其能在 TLS 握手阶段的 Server Hello 响应中启用signed_certificate_timestamp 扩展，传递 SCT 信息

我这里使用第三种方法，通过给tengine增加第三方模块nginx-ct 来使用tengine支持CT

下载相关文件：

git clone https://github.com/grahamedgecombe/nginx-ct.git

重新编译tengine，并加载nginx-ct模块

 ./configure --prefix=/webdata/opt/local/tengine --with-jemalloc --with-jemalloc=/usr/local/jemalloc --with-http_ssl_module --user=www --group=www --with-pcre --with-http_spdy_module --with-http_v2_module --with-openssl=/usr/local/openssl --add-module=/root/nginx-ct

make;make install

然后从下面地址下载一个小工具，这个工具用来向CT Logs服务器提交证书，并得到SCT响应。

git clone https://github.com/grahamedgecombe/ct-submit.git

工具又go语言编写，需要安装go语言的支持，yum install -y golang

然后

cd ct-submit;go build

编译成功后，会出现一个ct-submit的文件，

然后，到https://www.certificate-transparency.org/known-logs（翻墙自备梯子） 找几个CT Logs服务器提交你的证书链，并把结果保存到一个文件中。、

注意：证书链至少包含站点证书和中间证书，按顺序站点证书在上面，接下来是中间证书，根证书（可选）在最下面。

在上面为数不多的CT logs中竟然有两家中国公司 的CT Log server，

WoSign(沃通，2016年7月之后沃通签发的所有证书都支持CT) ,CNNIC(中国互联网信息中心)

本来想向一台google的 CT log 提交信息，无奈国内防火墙太厉害，根本连接不上google的服务器，所以选择了symantec和wosign的服务器提交了请求。可笑的是，当我向CNNIC的

服务器提交请求的时候，我的linux服务器竟然不认识它签名的证书，无奈只好作罢。

                                        服务器没有内置CNNIC的根证书，拒绝请求。

下面是向vega.ws.symantec.com(赛门铁克)和ctlog.wosign.com（沃通） 的ct 服务器提交证书信息，并把结果保存到文件中。

最后，修改 Nginx 配置，加入以下两行并重启服务即可：

ssl_ct on;

ssl_ct_static_scts /root/scts;

重启tengine即可

Certificate Transparency 与 Chrome

最后，说了这么多，如果不启用 CT 会有什么后果呢？实际上，对大部分网站影响都不大。首先 CT 策略目前只有 Chrome 支持；其次 Chrome 也知道现在支持 CT 的网站并不多，所以对于没有提供 SCT 信息的 HTTPS 网站也没有太大的影响。

对于使用 EV 证书的网站，如果没有按要求提供 SCT 信息，从 2015 年 1 月 1 日开始，Chrome 不会显示小绿条（详细要求可以看这个页面）。一般 EV 证书提供商都会把 SCT 信息嵌入到证书之中，大家如果有 EV 证书可以检查一下。万一证书里没有嵌入 SCT 信息，那最好通过 TLS 扩展的方式启用 CT，不然买了 EV 证书，Chrome 不给显示小绿条还是挺亏的。

对于其它类型的证书（OV、DV 等），如果没有提供 SCT 信息，最新的 Chrome 只是会在点击地址栏小绿锁时给出说明，内容如下：

The server did not supply any Certificate Transparency information.
服务器未提供任何 Certificate Transparency 信息。

Chrome 的这个提示内容有过调整，之前是这样的：

The identity of this website has been verified by ‍ but does not have public audit records.
该网站的身份已通过 ‍ 的认证，但没有公开审核记录。

而提供 SCT 信息之后，Chrome 的提示是这样的：

The server supplied valid Certificate Transparency information.
服务器提供了有效的 Certificate Transparency 信息。

本站的显示信息如下：

使用EV（扩展验证型证书）证书，大部分都内置CT支持了

不支持CT的站点如下所示：