经过七个月的漫长历程，著名的 火狐浏览器 FireFox 背后的厂家 Mozilla 终于选定了新 Logo。这次评选始于去年六月的 Mozilla 品牌重建活动，在八月份时已经圈定了七种设计，然后经过了上千封电子邮件、近百场会议、讨论了十几种理念，又经过了三轮研究之后，终于——选定了最初就被大家看好 Logo 设计：

moz://a

这个项目的核心是 Mozilla 需要让其目标与品牌更好地被更多人了解。Mozilla 希望引领一个健康的互联网，可以自由探索、发现和创新，而没有任何障碍和限制；让权力掌握在更多人手中，而不是少数人手里；让互联网成为一个安全、隐私和身份得到保护的地方。

Mozilla 称：

今天，我们相信，这些准则比以往更加重要。作为一个非盈利组织，我们正在产品构建、技术和程序方面为建设一个不断增长的、健康的互联网而努力。

我们的品牌标识，包括 Logo、声音和设计，都是传递我们的理念和我们当前任务的重要信号。我们致力于确保互联网成为一个健康的全球公共资源，公开而自由，所以我们以互联网语言设计了我们的品牌标识。

Mozilla 的新 Logo，采用 URL 范式，这代表了 Mozilla 的核心是 Internet，致力于达成“链接”的本意：无过滤、无中介地感受 Internet 丰富的内容。

新的 Logo 十分巧妙地将 “mozilla” 这个单词中的 “ill” 变形为 URL 的资源定位符号“://”， 这个 Logo 的设计得到了互联网上的广泛赞誉。

顺便提一句，这个 Logo 的字体叫做 Zilla ，是由 Mozilla 的长期合作伙伴 Typotheque 专门设计的，这个字体是自由开放的。

虽然并非微软官方出品，不过你现在可以在 Windows 10 的 Linux 子系统（WSL）中使用 openSUSE Leap 或 SUSE Linux 企业版（SLES）了。

正如你所知道的，最新的 Windows 10 版本中含有一个完整的、基于 Ubuntu 的 Bash，开发者们可以在 Windows 桌面中直接运行 Linux 软件或命令。这被称为“Bash on Ubuntu on Windows”——一个啰嗦的名字——现在可以从 Windows 的开始菜单直接访问到了。

不过，SUSE 的资深产品经理 Hannes Kühnemund 却表示，以他自己的观点来看，微软在选择 Linux 发行版时选“错”了——明显应该选 openSUSE 嘛。

“在 Windows 上原生地运行 Linux 二进制程序……这听起来真棒！然而，十分不幸是，微软在 WSL 里面选用了一个错误的 Linux（当然，这是我个人的看法），而现在是我们让它回到轨道上的时候了。” Hannes Kühnemund 说到，“为啥选 SUSE？因为 SUSE 从 1992 年开始就在做 Linux 发行版了。想找一个资格更老的 Linux 厂商（也可以叫发行版），对不起，你找不到，根本就木有！”

好吧，不管怎么说，如果你也对此感兴趣的话，他还写了篇文章教给你如何在 Windows 10 的 WSL 中安装 SUSE。

在 Windows 10 中安装 openSUSE Leap 42.2

如果你是 SUSE 粉，而你又想在 Windows 10 中使用你喜爱的 SUSE，但是又厌倦了使用虚拟机或配置双引导，那么就跟着 Kühnemund 先生一起来吧，他会教给你如何在 WSL 中安装最新的 openSUSE Leap 42.2。

首先，你需要按照微软的说明启用 WSL，也可以参考我们之前的介绍。确保在安装过程中创建了一个普通用户（带口令）。

这些步骤也同样适用于 SUSE Linux 企业版（SLES） 12 SP2，不过你需要下载另外一个文件。

运行如下命令下载 openSUSE Leap 42.2 的 docker 用户空间：

wget -O openSUSE-42.2.tar.xz https://github.com/openSUSE/docker-containers-build/blob/openSUSE-42.2/docker/openSUSE-42.2.tar.xz?raw=true

然后从开始菜单中打开 Linux bash shell，并执行如下命令来解压，然后退出 shell：

sudo mkdir rootfs
sudo tar -C rootfs -Jxf openSUSE-42.2.tar.xz
exit

如果在运行这些命令时出现一些警告，可以忽略。

完成之后，备份当前的“Bash on Ubuntu on Window” 安装：

cd %localappdata%\lxss\
rename rootfs rootfs.ubuntu

然后复制新的 openSUSE Leap 42.2 的根文件系统 rootfs：

move .\home\rootfs .\

最后，设置 root 为默认用户：

lxrun /setdefaultuser root

这样，下次你再访问 bash 时，你就用的是运行在 WSL 中的 openSUSE 或 SLES 啦。

当然，你还可以再做的完美些。用这个绿绿的 SUSE 图标替换 “Bash on Ubuntu on Window” 默认的橘红 Ubuntu 图标：

cd %localappdata%\lxss\
rename bash.ico Ubuntu.ico
rename Saki-NuoveXT-Apps-suse.ico bash.ico

在 Windows 10 中运行 SUSE Linux shell

哦，除了图标，启动菜单中的名字 “Bash on Ubuntu on Window” 显然你也想换过来，进到 %AppData%\Microsoft\Windows\Start Menu\Programs，把默认项改成“Bash on SUSE on Windows” 或其它你想要的什么名字。

其它发行版呢？

如果你喜欢其它 Linux 发行版，比如 Arch Linux，那么你可以看看这篇文章。

还能支持别的 Linux 发行版吗？你别说，还真有人做出了一个工具，可以在 WSL 中支持大多数的 Linux 发行版，并可以在这些发行版之间切换自如。

这个工具是由 RoliSoft 贡献到 GitHub 上的，名为 WSL-Distribution-Switcher 。其思路类似于上面 openSUSE 的思路，都是采用容器作为 WSL 中的根文件系统。

你可以通过该工具中的 get-prebuilt.py 或 get-source.py 从 Docker Hub 上下载各个发行版的官方镜像或 tar 包，然后用 install.py 安装即可。最后，你还可以通过 switch.py 在你下载安装的 WSL 中进行切换。具体的操作，请参考其说明。

由于它使用的是 Docker Hub 官方镜像，因此，它可以支持大多数 Linux 发行版，比如：

• debian
• ubuntu
• fedora
• centos
• opensuse
• mageia
• oraclelinux
• alpine
• crux
• clearlinux
• ……

怎么样，你有试过在 Windows 10 中的 WSL 里面运行 Linux 吗？

via：softpedia，suse，github，microsoft

不知道多少次了，我在微信公众号后台收到询问“你们的微信文章版式是怎么做的”等问题了。其实，我本来觉得这没什么值得问的，也不值得保密，但是总是有人问，我觉得还是写一篇小文来介绍一下吧，下次有人问我，我就直接丢链接好了~

我本身不是做美工和 UI/UE 出身的，但是我们的（前）联合创始人 DeadFire 是专门做这个的，奈何他再也不可能为 Linux 中国做任何的 UE 调整了，/cry。不过我们的 UE 在他的努力之下，目前还算不错，也仅以这些样式来纪念他吧。

下面我来说说我们的微信文章版式的几个算是亮点的地方吧。

先说一个前提，Linux 中国的文章都是通过自身网站的 CMS 进行编辑的，并没有使用外部的那些第三方的微信编辑器。因此，如果你有一个可以编辑内容并形成网页的 CMS，那么以下技巧可能就比较适合你使用；如果你没有 CMS ，理论上说你手工编辑 HTML 页面也是可以的；或者，其实你可以复制我们的文章的格式到一个可视化 HTML 编辑器中，修改内容也可以。

1、代码高亮

作为技术网站，刊载的文章中出现代码是必不可少的，之前我们也用过一些代码高亮插件，但是因一些不足后来就放弃了。

目前我们使用的代码高亮插件是 Google 的 code-prettify，最初它是放在 Google Code 上的，现在也托管到了 GitHub： https://github.com/google/code-prettify 。

code-prettify 的优点是体积小，使用简单，而且自动识别所高亮的语言（虽然有时候识别的不对，但是其实没几个人真的在意对不对，大致能区分不同的语言成分就好了）。目前这个软件已经有比较长的时间不更新了，虽然还有 bug，不过大致上的功能没有什么问题。

使用方法很简单，首先你得在页面中引入 code-prettify 的 js 文件，然后在你要高亮代码外使用 <pre class="prettyprint">...</pre> 或 <code class="prettyprint">...</code> 标签即可。比如：

<script src="run_prettify.js"></script>
<pre class="prettyprint">class Voila {
public:
  // Voila
  static const string VOILA = "Voila";
}</pre>

然后看起来效果就是：

class Voila {
public:
  // Voila
  static const string VOILA = "Voila";
}

可能你使用了 code-prettify 之后也发现和我们的代码样式不同，其实，这只是我们使用了自己定制的一个 CSS 样式罢了，稍微研究下我们的页面代码，你就能找到这个 CSS 的，你可以根据你的喜好进行修改。

当你做好了一个可以在浏览器中满意呈现的页面之后，你只需要复制该页面内容，贴到你的微信后台的编辑器中即可。

2、英文注释标签

我们经常会发布各种英文文章的译文，但是有时候，一些词汇需要附上英文才能比较好的避免歧义。通常大家的做法都是在中文后面用括号圈上对应的英文，但是随着 HTML5 规范的普遍支持，其实还有另外一种新的标签可以更好的用于这种情况。那就是 RUBY 标签。

RUBY 是振假名的意思，用于在 HTML 中标注注音。各个浏览器对 RUBY 标签的支持程度不同，不过最基本的用法都是支持的，包括微信内的浏览器。

简单的来说，RUBY 标签的基本格式如下：<ruby>这里写中文<rt>English here<rt><ruby>，这个标签用浏览器看的效果是这样的： 这里写中文 （ English here ） 。

当然，实际上 RUBY 标签还许多子标签和不同的格式变体，但是一方面各个浏览器支持效果不同，另外一方面对微信浏览器而言仅支持这种基本格式。需要深入研究的同学可以自行搜索。

目前应该还没有支持 RUBY 的 CMS，所以，一般情况下你需要手工编辑你的页面的 HTML 来插入这种标签——当然，我是自己开发了一个我的 CMS 的插件。

此外， RUBY 标签也是可以嵌入链接的，这种情况也比较常见。你可以自行摸索下。

最后，RUBY 标签自然有默认的显示样式，显然，作为在意用户体验的你，肯定会给它单独调整下 CSS 的，是吧？

3、其它

实际上，除了以上两点，我们并没有特别不同的地方，不过用户体验的细节还是有所调整的，但是这些就是见仁见智的地方了，大家可以根据需要参考我们或其它一些在页面体验方面有所特长的页面进行学习。

除此以外，做了几年的微信文章发布，我还有一点点小经验可以分享给大家：

• 不建议调整正文字号，就用默认的 16px 即可，虽然看起来比较大——但是现在移动设备分辨率越来越高了，所以较小的字号可能会让部分用户看起来比较累。当然，也可以考虑使用 14px，如果你的文章不全是密密麻麻的字的话。
• 正文文字的颜色不要出现太多，除了黑色以外，最多有两种为宜。此外，在特殊情况下，你还可以考虑使用加粗，甚至斜体效果。
• 中英文混排时，以及掺杂数字时，尽量在英文单词与汉字之间加个空格，关于这方面，网上有篇《中文排版指北》，会有更详细的建议，不过我认为最重要、最基本的就是这条了。
• 文内配图，如果有可能尽量尺寸一致，最少要考虑保证图片宽度一致比较好。配图下方，必要时可以用另外一种文字样式来做图片说明。比如我们就是用斜体、灰色、下划线样式的字体作为图片说明。模糊的配图不要也罢，除非必要，用动图会显得很 low——有些老网友或许还记得 20 年前的网页上的那种 GIF 动画展览吧？
• 题图，如果你的标题不够好，那就选张好的题图吧，如果你能有一张切题的壁纸级题图，那显然会让你的公众号订阅者更高兴一些——如果细心的话，或许你可以放上这张壁纸级题图的高分辨率原图的 URL 地址？
• 微信后台的文章编辑器对很多 HTML 标签是不支持的，比如 DIV。所以，大家如果采用 div 布局的话，会发现桌面浏览器上看的好好的样式，复制到微信后台的编辑器中会变得惨不忍睹。这种情况下，你可以考虑用一些新的块级元素，比如 SECTION。

• 链接，微信文章仅在一些特定的情况下支持文内链接，所以，对于大部分公众号的微信文章来说，都是没办法在文内加上链接的。但是作为 Web 世界，有时候明明有链接的地方你不提供链接，你可以想象读者的怒火。这时候，我们有两种方式可以稍微补救。

  1. 对链接的文字加上特定样式（如加上下划线），以暗示此处有链接，然后在后面加个上标，比如 ^[1]，并在文末单独对这个上标提供链接，这样需要的读者可以复制该链接访问。不过要注意的是，微信文章不支持 SUP 标签，你可以用 SPAN 标签来达成类似效果。
  2. 如果文内链接不多，链接本身也不算长，你可以用括号圈起来写上链接，不过如果链接太多，也太长时，这会影响正文阅读效果的。其实这两种方式都是仿照纸质书籍这种无法做到超链接的出版物的。
• 对于长文章，你应该考虑在文内提供不同层次的大小标题。如果有可能，你还应该在页首提供一个目录、摘要等信息。当然，我们使用了 CMS，这种信息是自动提取生成的，可能要方便一些。

好了，大致我就总结这些，希望对大家有所帮助，如果有什么问题，请留言讨论，也欢迎大家分享自己的经验。

（题图来自：picswalls.com）

昨晚偶尔清理 Chrome 插件时发现我的 “HTTP/2 and SPDY indicator”插件好像好久没亮了。这个插件在你访问到一个支持 HTTP/2 （或之前的 SPDY 协议）的网站时会点亮，而我明明记得之前专门让 https://linux.cn/ 支持了 HTTP/2 。

我的第一反应是不是这个插件有问题了？于是打开 Chrome 调试工具，然后发现，真的是请求和响应都是 HTTP/1.1 哎！

经过一番研究，原来是从 Chrome 51 开始，在 2016 年 5 月 31 日之前，对支持 NPN 协商协议的 HTTP/2 网站还会采用 HTTP/2 访问；而之后就只支持 ALPN 协商协议的 HTTP/2 网站了——而目前 ALPN 协议仅被鲜少有发行版支持 openssl-1.0.2 支持。

发生了什么？

服务器端

我们知道，最初的 Web 访问协议是 HTTP/1，包括以前的 HTTP/1.0 和现在大部分网站采用的 HTTP/1.1（HTTP/0.9 是试验性协议，已经废弃）。但是随着 Web 应用越来越复杂，之前的 HTTP/1.x 协议就看起来不能满足日益庞杂的 Web 服务需求了。比如说，明文请求、请求复用等问题。因此，谷歌就开发了一个新的传输层协议，名为 SPDY。由于这个新的协议用了的人都说好，因此谷歌就把这个协议提交到了 IETF，然后大家觉得，SPDY 这名字不好听（SPDY 是谷歌的注册商标），就干脆叫 HTTP/2 吧！

SPDY 协议是基于 SSL/TLS 的，谷歌开发了一个名为 下一代协议协商 （ Next Protocol Negotiation ） （NPN）的 SSL/TLS 扩展，用于在客户端连接服务器时协商是否采用 HTTP/2 协议。SPDY 协议是由 Web 服务器所实现支持的，而 NPN 则是由 OpenSSL 等 SSL 实现支持的。

但是，随着 SPDY 被提交到 IETF，然后变成了 HTTP/2 协议，谷歌也放弃了 SPDY 的开发，全力投入到了 HTTP/2 的开发中，之前所采用 NPN 也被一种新的协商协议 ALPN —— 应用层协议协商 （ Application-Layer Protocol Negotiation ） 所替代。NPN 和 ALPN 是不兼容的，它们的主要不同是：

• NPN 是服务器发送所支持的协议列表，由客户端进行选择。而 ALPN 则是客户端发送该列表，由服务端选择。
• 在 NPN 中，最终的选择结果是在 Change Cipher Spec 之后发送给服务端的，也就是说是被加密了的。而在 ALPN 中，所有的协商都是明文的。

这样做的好处主要是安全性方面的考虑，但是这造成了一个问题就是，NPN 已经广泛地被 OpenSSL 支持，而 ALPN 则目前只有最新的 openssl-1.0.2 才支持。当前的几个主流 Linux 发行版的 OpenSSL 版本以及支持的协商协议如下：

从上面我们可以看到，基本上所有的服务器级的 Linux 发行版都不支持 OpenSSL 及 ALPN，唯一支持的 Ubuntu 16.04 LTS 显然用的不会很多。不要小看这 0.0.1 的版本差异，对于别的软件来说这 0.0.1 的差异基本上可以忽略，但是对于 OpenSSL 来说，那就是两个版本代际。OpenSSL 是个相当底层的库，很多重要的软件都依赖于它，因此各个发行版在升级 OpenSSL 时采用的态度是相当保守，比如我们可以看看 CentOS 系统中有哪些软件使用了 OpenSSL：

$ lsof | grep libssl | awk '{print $1}' | sort | uniq
anvil
fail2ban
gdbus
gmain
httpd
postfix
mysqld
NetworkManager
nginx
php-fpm
puppet
sshd
sudo
tuned
zabbix_agent

没有经过足够的测试，Linux 发行版是不会在产品级（服务器级）的环境中随便升级的。为了解决旧版本（1.0.1）中的安全问题，他们宁可将新的版本（1.0.2）中安全修复移植回旧版本，也不会升级到有新功能的新版本（1.0.2），这就是你见到了各种 1.0.1e、1.0.1k 这样的版本号的原因。

当然，你可以自己编译一个最新 OpenSSL 替代你系统中的 openssl-1.0.1，但是我想你不会这样做的，是吧？

顺便提一句，NPN 和 ALPN 可以并存，但是会客户端会优先选择 ALPN。

浏览器端（Chrome）

从 Chrome 51 开始，谷歌就去掉了对 SPDY 的支持，不过这不是个事，因为不但使用 SPDY 的 Web 服务器比较少，而且从 SPDY 升级到 HTTP/2 也很简单，这方面 Nginx、Apache 等服务器的配置都很简单。

但不幸的是，在 Chrome 51 中，谷歌也去掉了对 NPN 的支持！如果你的 Web 服务器使用的是 openssl-1.0.2 以下的版本，不支持 ALPN 协商，那么 Chrome 51 及以后版本就会以 HTTP/1 协议访问你的网站。

谷歌对放弃 NPN 支持做了一个简短的解释，但是不管怎么说，NPN 协议在 Chrome 51 之后的版本不会再次回来了。而另一方面，OpenSSL 在 2016 年 12 月 31 日之后也不会继续发布 openssl-1.0.1 系列的新版本了，安全修复到此为止。

而在这种情况下，你原本支持 HTTP/2 的网站通过连接复用等 HTTP/2 所提供的新特性，在 Chrome 下访问取得了不错的体验，而现在又跌回了之前的残旧状态。

怎么办呢？

有几种办法：

换浏览器

山不来就我，我去就山。Chrome 51+ 不支持带 NPN 的 HTTP/2 网站，作为浏览者，你可以使用其它的浏览器，比如 Safari、Edge 之类的。这样，你就可以用新的协议来访问世界上那 10% 支持 HTTP/2 的 Web 服务器了。

但是，作为服务器运营者，你却不能忽视高达 50% 以上的 Chrome 用户。

换服务器

如上面所示，Ubuntu 16.04 LTS 是目前唯一官方支持 openssl-1.0.2 的 Linux 发行版，如果你一直采用 Ubuntu 做服务器，考虑一下升级吧。LTS 版本的支持期长达五年。

当然，在产品环境中，即便你是 Ubuntu 服务器，更新版本也是一件重大事宜，宜慎思之。

重新编译

既然换服务器不是一个好的选择，那你还有一个方案，就是使用新的 openssl-1.0.2 源代码重新编译你的 Web 服务器，比如 nginx。

下面我简单介绍一下如何用 openssl-1.0.2 来编译 nginx。（1.0.2 系列的最新版本是 1.0.2j，当然你要非用 1.1.0，我也无话可说……）

首先下载并解压 openssl-1.0.2j：

# wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz
# tar -zxvf openssl-1.0.2j.tar.gz

然后在编译 nginx 的时候使用 --with-openssl=../openssl-1.0.2j 选项以及你的其它选项：

./configure --with-openssl=../openssl-1.0.2j --with-http_v2_module --with-http_ssl_module

配置并编译之后，你可以用 nginx -V来看一下你的 nginx 中的 OpenSSL 版本。

这种自行编译的好处是灵活性高，但是你需要随时注意各个组件是否有严重的安全漏洞，并在出了修复版本之后重新编译。

容器

除了自己编译之外，如果你的系统环境中已经有了容器支持，你还可以在容器中运行一个 Ubuntu 16.04 LTS，并将 Web 服务器运行在其中。

总结

以上就是 HTTP/2 和 Chrome 之间的故事，你准备去升级 HTTP/2 支持了吗？要知道相比 HTTP/2 的访问体验，你肯定不会想再回到 HTTP/1 了。

最近关于沃通和 StartCom 这两家 CA 公司的消息让人们再次关注到了网络隐私和安全的问题。随着 Mozilla、苹果和谷歌对这两家 CA 公司处罚落定，很多使用这两家 CA 所签发证书的网站纷纷寻求新的证书签发商。这里面固然有不少可信赖的 CA 公司可以提供服务，不过，有另外一个非盈利组织却为大家提供了免费、可靠和安全的 SSL 证书服务，这就是 Let's Encrypt 项目。

Let's Encrypt 项目是由 互联网安全研究小组 ISRG，Internet Security Research Group 主导并开发的一个新型 数字证书认证机构 CA，Certificate Authority 。该项目旨在开发一个自由且开放的自动化 CA 套件，并向公众提供相关的证书免费签发服务以降低安全通讯的财务、技术和教育成本。

网站的完全加密是非常有必要的，这样每个人都可以随意在网上畅游而不用担心他们的活动被监视、拦截和修改。

Let’s Encrypt 的做法与一般的 CA 服务商不同。他们为那些需要加密的网站提供了免费、易用的获取和管理证书的服务，而且在全球的每一个国家都可以使用。这些服务可以帮助人们或组织战胜来自经济、技术和培训方面的障碍，在互联网上安全地通讯。

仅仅在 Let’s Encrypt 运营了 10 个月之后，加密的页面数量就有了快速提升！这里面，Let’s Encrypt 项目居功甚伟，采用加密 Let’s Encrypt 的页面 90% 都是之前从未进行过加密的。

然而，互联网上还有超过一半的页面仍然没有加密。所以 Let’s Encrypt 还任重而道远，为了达成让互联网全都变成加密的这一目标，他们需要你的帮助！因此 Let’s Encrypt 在众筹网站 generosity.com 上发起了众筹，募集更多的运营资金，以期做的更好！

如果您能捐助他们，您就为建立一个更安全的互联网埋下了一块基石。您所捐赠的每一块钱，都可以帮助 Let’s Encrypt 为所有用户创建一个尊重隐私的互联网体验。

他们划定了几个从 $25 到 $42000 不等的捐赠级别，并且为了感谢您的支持，会提供给您一些有趣的礼品以示谢意：

第一个级别 $25，您将收到一声感谢！

第二个级别 $50，您将收到一些精美的贴纸，可以贴在你的保险杠、水杯或者其它的什么地方。

第三个级别是 $100，他们叫这个“To Encryption and Beyond!”，礼品是这些漂亮的、合身的 T恤。

如果您捐赠了 $250，您将同时收到 T 恤和贴纸。

更高额度的捐赠就不在这里一一列出了，富有爱心的土豪可以移步这个众筹网站去看看。

如果您暂时手头比较紧张，你还有其它的几种方式支持：

• 分享这篇文章或其中的视频到你常用的社交媒体中。
• 转发这个的捐赠计划。
• 参与他们的社区论坛。
• 帮助他们找到 bug 以便可以修复它。

关于 Let's Encrypt 的更多信息，您可以访问其官网： https://letsencrypt.org/ ；如何使用他们的服务，你可以参考这篇文章。

继 Mozilla 做出对 沃通 （ WoSign ） 的处罚决定之后，谷歌也跟随了这一做法，从 Chrome 56 开始，不再信任沃通及被其收购的 StartCom 于 2016 年 10 月 21 日之后所颁发的证书。

此前， 苹果已经率先于 9 月 30 日将沃通的根证书从证书存储库中移除了。虽然沃通及其被其秘密收购的 StartCom 均存在不同程度的 CA 违规问题，但是苹果和 Mozilla 在最近的操作中都只对沃通采取了处罚，而谷歌的处置则更进一步，也同时对 StartCom 进行了同等处罚。

谷歌在其通告中说：

谷歌已经查明了沃通和 StartCom 这两个 CA 没有维持对其作为 CA 的高标准预期，因此根据我们的根证书策略，谷歌 Chrome 将不再信任它们。这个观点类似于苹果和 Mozilla 的根证书计划发出的最近公告。

在 2016 年 8 月 17 日，谷歌接到了 GitHub 安全团队的通告，称沃通在没有得到他们授权的情况下签发了一个 GitHub 的证书。这促使 GitHub 安全团队和 Mozilla 合作对沃通进行了调查，发现了沃通的若干违规签发证书的问题。该调查表明沃通有意地规避了浏览器限制（即对 SHA-1 签名证书的失效计划）和对 CA 的要求。更进一步的，还发现了另外一家 CA 公司 StartCom 也被沃通秘密收购，这违反了对 CA 公司被收购需要披露信息的要求。而且，沃通公司还替换了原 StartCom 的基础设施、人员、政策和签发系统。面对这种情况，沃通和 StartCom 管理层还尝试误导社区这两个公司之间的收购事实和关系。

谷歌于 10 月 31 日发布了 Chrome 56 的 Dev 渠道版本。谷歌决定从该版本的 Chrome 开始，不再信任沃通和 StartCom 于 2016 年 10 月 21 日之后签发的证书。在这个日期之前签发的证书依旧信任，但是之后，除非他们遵循 Chrome 的证书透明策略，将只能对其已有客户的域名签发。按照计划，Chrome 56 将于 2017 年 1 月正式发布稳定版，因此在此之前，使用这两个 CA 所签发证书的网站应该尽快迁移到其它被 Chrome 信任的 CA 所签发的证书下。

沃通和 StartCom 的客户会发现他们的证书在 Chrome 56 中不再有效。并且，更严厉的是，谷歌还说：

在接下来的 Chrome 版本中，还会进一步减少对这两个 CA 签发的证书的支持，直到最终完全移除对这两个 CA 的信任！

并且称：

沃通和 StartCom 的任何试图规避处罚的做法都将导致这两个 CA 被马上全部移除！

沃通的证书在国内使用比较多，而 StartCom 的 StartSSL 证书则在全球范围内有广泛的使用，尤其是它的免费证书有很多个人网站在使用。鉴于 Chrome 在浏览器市场上已经占据了一半左右的份额，因此其带来的影响将是毁灭性的。

目前，主流浏览器里面，Mozilla 的 Firefox 、苹果的 Safari 和谷歌的 Chrome 都已经做出了相应的反应，但是我们目前还没见到微软对此的跟进和表态。似乎微软在 CA 策略方面一向比较散漫，因此，IE 和 Edge 浏览器的反应或许还需要一段时间，抑或不会采取措施。