自从关注了 HTTPS，Linux 中国就成了 HTTPS 的铁杆粉丝了，不但传播了很多 HTTPS 相关的文章，而且身体力行的将 http://linux.cn也[切换](/article-5361-1.html)到了https://linux.cn 。非但如此，还激进地配置了 HSTS 策略。

HSTS 是什么？

如果一个 web 服务器支持 HTTP 访问，并将其重定向到 HTTPS 访问的话，那么访问者在重定向前的初始会话是非加密的。举个例子，比如访问者输入 http://www.foo.com/ 或直接输入 foo.com 时。

这就给了中间人攻击的一个机会，重定向可能会被破坏，从而定向到一个恶意站点而不是应该访问的加密页面。

HTTP 严格传输安全（HSTS）功能使 Web 服务器告知浏览器绝不使用 HTTP 访问，在浏览器端自动将所有到该站点的 HTTP 访问替换为 HTTPS 访问。

服务器开启 HSTS 的方法是，当客户端通过 HTTPS 发出请求时，在服务器返回的 HTTP 响应头中包含 Strict-Transport-Security 字段。浏览器接收到这样的信息之后，在一定期限内对该网站的任何请求都会以 HTTPS 发起，而不会以 HTTP 发起并由服务器重定向到 HTTPS。

所以，我们早早就配置上了 HSTS 响应头了。

当前浏览器对 HSTS 的支持如下，可见现代浏览器已经绝大部分支持了：

HSTS 预载入列表

但是，这就够了么？如果一个用户从来没有以 HTTPS 方式访问过我们的网站呢，那显然就没有机会得到 HSTS 响应头，从而还是有可能以 HTTP 的方式进行首次访问——虽然我们已经做了很多自动和强制的引导，但是总还稍有缺憾？

所以，追求完美人们，又提出了一个 HSTS 预载入列表 （ preload list ） （友情提示，请自备梯子）。

谷歌在浏览器安全方面总是走在前面，因此它维护了一个预载入列表给 Chrome 使用，这个列表会硬编码到 Chrome 浏览器中。后来，Firefox、Safari、 IE 11 和 Edge 一想，得了，咱也别自己弄一个了，都采用这个列表吧。所以，各大浏览器都支持同一个列表了。

如果要想把自己的域名加进这个列表，需要满足以下条件：

• 有效的证书（如果使用 SHA-1 证书，必须是 2016 年前就会过期的）；
• 将所有 HTTP 流量重定向到 HTTPS；
• 确保所有子域名都启用了 HTTPS，特别是 www 子域；

• 输出 HSTS 响应头：

  • max-age 至少需要 18 周（10886400 秒），其实在 ssllabs 的测试里面建议更长一些；
  • 必须指定 includeSubdomains 参数；
  • 必须指定 preload 参数；

HSTS 响应头范例：

Strict-Transport-Security: max-age=10886400; includeSubDomains; preload

注意，提交的申请并不是自动处理的，人工处理也许需要一周到几周，你可以在这个表单提交查询看看是否列入了。或者在你的 Chrome 浏览器中访问 <chrome://net-internals/#hsts> 查询是否列入。一般来说，即便你已经列入到这个列表，但是依旧需要几个月才能逐渐从 Chrome 的 canary 更新通道更新到 dev 、beta 等通道，直到最后的 stable 通道。

郑重警示：如果你并不能确定你的网站从此以后一直使用 HTTPS，那还是不要加入的好。因为，加入后很难撤销，你可以要求撤销，但是这个数据重新更新到稳定版的 Chrome 同样需要几个月，而别的浏览器是如何处理这个撤销数据的，则无法保证。

换句话说，只有 HTTPS 骨灰粉才应该考虑加入。

我们就是 HTTPS 骨灰粉！

任性的站长当然是 HTTPS 骨灰粉了，虽然“一入宫门深似海”，将来 HTTPS 会不会和 L2TP、PPTP 一样被限制也未可知，但是这么有 BIG 的事情怎么可以不做呢？

上个月15号，我修改了符合申请条件的 HTST 响应头，然后提交了申请。

今天晚上突然心血来潮，想着看看是否批准下来了：

哈哈，通过了！

然后马上去 Chrome 里面查询——没有……好吧，我用的是稳定版的 Chrome。去下载 canary 通道的 Chrome 看看。安装后马上查询一下：

果然列入了 canary 通道的 Chrome 里面！第一次在这个新开封的浏览器里面访问 linux.cn，马上就变成绿色的 https://linux.cn ！

去查询一下 Chrome 的代码看看：

从现在的数据看，列表中总共才 4630 个域名，其中 .cn 的才 8 个。怎么样，你要不要也加入进来？

据外媒 Softpedia 消息，移动数据领域的初创企业 Wandera 最近的一份调查报告显示，包括加拿大航空、亚航等四家大型航空公司在内的全球十余家航空、铁路、出租、票务等方面的大型公司由于没有部署移动端 HTTPS 访问，导致用户信息存在巨大的泄露风险！这些公司往往都已经在其网站上部署了 HTTPS 服务，但是其提供的针对手机的移动网站和 app 客户端的访问上，却没有相应的也使用 HTTPS 服务。这就导致了它们为每日高达50万用户访问所提供的服务存在着巨大的信息泄露风险。

尤其是当用户使用不可靠的公用互联网接入，如咖啡馆、商场的免费 WIFI，通过手机浏览器或 app 客户端访问这些没有采用 HTTPS 的服务时，就存在很大的被截获各种私人敏感信息的风险，比如身份信息、用户名、密码，乃至于信用卡号码等。这些数据泄露风险从何时开始，造成了多大的数据泄露已不可考。报告披露后，已有公司采取技术手段解决了该安全风险。

该调查主要针对欧美国家，并未涉及到中国国内情况。但是据我们对国内的网站、移动网站及 app 客户端的 HTTPS 部署情况的了解，这种风险同样存在，甚至会更严重。

而另一方面，据 CNNIC 调查数据显示，截止至 2015 年上半年，手机支付、手机网购、手机旅行预订用户规模分别达到 2.76 亿、 2.70 亿和 1.68 亿。同样据 CNNIC 数据，超过 40% 的人会使用网吧、公共场所等场所的 WIFI 接入互联网。

综合来看，采用移动客户端进行网上交易，当使用不安全的网络接入时，如果所访问的网站又没有做好必要的安全措施时，就有很大的风险泄露访问者的个人敏感信息。

怎样才能避免这样的风险？难道不能网上订票了吗？

其实，避免这样的安全风险的解决方案已经有了，那就是网站服务商应该向用户提供符合安全标准的 HTTPS 服务，而不是采用老旧的、不安全的 HTTP 服务。这样，即便访问者所处的环境并非十分安全可靠，依旧可以极大地降低用户的风险。

什么是 HTTPS 呢？

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标建立客户浏览器端与服务器端进行数据传输的通道，简单来说就是 HTTP 的安全版。它最初由网景公司创建出来并内置在其浏览器中。

HTTPS 之所以能够做到数据的安全传输，是通过 SSL/TLS 协议完成的。只有通信的双方才具备数据的加解密功能，而数据在中间通道的传输时已经加密。加密算法一般使用 AES 或 RSA 等，并且通过目前的科学分析，不大可能通过计算能力提升而使得正确配置的密码算法得到轻易地破解。

因此我们说，HTTPS是安全的。

为什么越来越多的网站选择 HTTPS？

近年来，重视安全的大厂商都在逐步加快网站部署 HTTPS 的速度。搜索引擎巨头 Google、淘宝天猫、百度等均全站启用 HTTPS，相信在未来，会有越来越多的网站加入全站 HTTPS 化的行列中。

为什么 HTTPS 如此受到青睐? 答案不言而喻，自然是因为 HTTPS 能够给网站带来更多的价值。这些价值主要体现在：

1. 确保了流量的安全性，被拦截窃听后也无法获取真实信息，避免了隐私数据在网络上外泄的可能。这也是为什么所有的金融、支付类网站强制要求必须为 HTTPS 服务的原因。
2. 安全性较高的网站往往在搜索引擎同类型中有着较高的排名。
3. 浏览器的可信标识能够加强普通用户对网站的信任感。

既然 HTTPS 能够对网站带来非常实用的价值，可以预测的是，在安全这个需求越来越受到网民以及网站管理者重视的趋势下，未来 HTTPS 将彻底取代 HTTP，成为网站数据通信的主流方式。

如何部署 HTTPS ？

简单来说，作为网站服务提供方，你首先需要购买被主流浏览器所认可的 CA 颁发的 HTTPS 证书；然后依据你的 Web 服务器的不同，如 apache、nginx ，采用不同的配置，提供监听在 TCP/443 端口 HTTPS 服务；最后，要测试你的 HTTPS 服务是否功能正常、性能是否受到影响、是否影响了用户体验等方面。

具体的技术描述，就不在这里逐一展开了，请根据你的 IT 基础架构进行部署。一般而言，对于小型网站来说， 部署 HTTPS 服务还是比较简单的，但是对于规模较大、业务复杂的网站来说，部署 HTTPS 服务还是一项艰巨的工程。此外，据闻阿里云准备推出进行 HTTPS 服务封装的分布式服务，可以将你的 HTTP 服务无缝地封装成 HTTPS 服务，并且同时提供了服务加速（CDN）、攻击防护（WAF）和流量清洗（DDoS/CC）等功能。

部署了 HTTPS 服务，终于可以放心了？

当你终于部署好了 HTTPS 服务后，看到浏览器地址栏中的绿色标示，是不是感觉成就满满——妈妈再也不用担心我的用户信息被偷走了 :D

但是，且慢，其实你还只是接上了一块短板，还有一块短板依旧在流淌着水呢。

由于 HTTPS 服务对传输的内容进行了加密，理论上说，只有服务器端和客户端才能正确加密和解密数据，因此，你以前所用的基于云的 WAF （Web 应用防火墙）可能不支持 HTTPS，从而没法为你提供对 XSS 、SQL 注入等应用攻击层面的防护能力了。

通常的安全产品不能很好的支持 HTTPS 网站防护。其原因主要有：

1. 目前的云防护或者是传统安全防护一般都是采用代理的模式。即采用将流量引入到安全防护产品中，通过检测分析，发现异常攻击，然后采取防护措施。但由于 HTTPS 对数据进行了加密，因此防护产品不能在应用层详细的解析出 HTTP 报文内容，自然不能识别攻击与合法流量，从而对威胁攻击束手无策。
2. 由于涉及到建立连接的握手加解密协商，HTTPS 需要消耗的性能通常是 HTTP 的数倍。一般的防护产品没有搭建大规模防护集群的能力，因此无力做到大流量的 HTTPS 防护。

那好吧，你还可以购买硬件的 WAF 防火墙，但是，当 DDoS/CC 攻击和流量攻击如洪水般涌来时，你的 WAF 和线路能支撑多久？

是不是感觉踩下一块板，又翘起来另外一块？由于部署了 HTTPS ，从而导致原本可以防护应用层面攻击的分布式 WAF 服务反而不能用了？

另外，还有一件可能令你感到悲伤的事情，作为访问量蒸蒸日上的你的网站，采用 CDN 提供分布式的访问支持那简直是一定的，但是，目前支持 HTTPS 的 CDN 服务商还很少。

怎么办？难道使用 HTTPS 服务是个错误吗？

我来告诉你一个完整的解决方案……

以下是广告时间，阿里云云盾高防产品……什么，原来是软文？！

好吧，我们来谈谈技术问题。

本质上来说，云防护产品支持 HTTPS 是可行的，但是这里需要解决几个问题：

1. 如何透明的解析 HTTPS 流量，并针对流量特征进行分析和处置？
2. 如何避免升级到 HTTPS 所带来的处理能力降低、性能衰减的问题？

针对此种情况，阿里云云盾高防产品特别推出了支持 HTTPS 的应用层防护功能。其技术原理图如下：

实现的步骤为：

1. 用户在云盾高防控制台中导入对应域名的证书和私钥、配置域名信息。
2. 客户端与云盾高防进行 SSL 握手协商，协商通过后，使用云盾颁发的证书及公钥加密数据。
3. 云盾高防进行数据解密，进行安全防护分析后，将合法的流量重新加密传至服务器端，同时阻断掉非法的攻击流量。
4. 服务器端进行数据解密，实现正常业务。

通过以上方式，在客户业务无任何改造的情况下，云盾帮助用户实现了全链路端到端的数据加密。与此同时，由于进行了数据解密，云盾具备了分析应用层数据的能力，因此具备了转发流量到指定地址，进行细粒度安全防护的能力。包括且不限于：

1. 高达 300G 的 DDoS 防护能力。
2. 海量的 CC 攻击防护能力（集群可支持千万级 QPS 的攻击流量清洗）。
3. Web 应用漏洞攻击的阻断防护能力（包括 SQL 注入、XSS、命令注入、木马 Shell 等通用 Web 攻击形式）。
4. 提供丰富多样的应用层数据报表，不仅包括安全的详细报表，同时也会覆盖到业务访问的数据情况。
5. 支持对部署在阿里云之外的主机的安全防护。

当然，如果您对数据隐私安全性要求比较高，可能会比较担心私钥放在云盾上的安全性。针对这种顾虑，也有对应的私钥安全解决方案。

另外，如果您对于自己部署 HTTPS 服务感觉棘手，阿里云云盾也有计划在近期推出 HTTP 直接变身 HTTPS 的服务，支持 HTTP 用户在无需更改自身业务的前提下，升级变为 HTTPS。

更多详情，可以戳戳这个链接看看。

如果你是一个负责维护和确保 web 服务器安全的系统管理员，你需要花费最大的精力确保服务器中处理和通过的数据任何时候都受到保护。

RHCE 系列：第八部分 - 使用网络安全服务（NSS）为 Apache 通过 TLS 实现 HTTPS

为了在客户端和服务器之间提供更安全的连接，作为 HTTP 和 SSL（ Secure Sockets Layer （ 安全套接层 ） ）或者最近称为 TLS（ Transport Layer Security （ 传输层安全 ） ）的组合，产生了 HTTPS 协议。

由于一些严重的安全漏洞，SSL 已经被更健壮的 TLS 替代。由于这个原因，在这篇文章中我们会解析如何通过 TLS 实现你 web 服务器和客户端之间的安全连接。

这里假设你已经安装并配置好了 Apache web 服务器。如果还没有，在进入下一步之前请阅读下面站点中的文章。

• 在 RHEL/CentOS 7 上安装 LAMP（Linux，MySQL/MariaDB，Apache 和 PHP）

安装 OpenSSL 和一些工具包

首先，确保正在运行 Apache 并且允许 http 和 https 通过防火墙：

# systemctl start http
# systemctl enable http
# firewall-cmd --permanent –-add-service=http
# firewall-cmd --permanent –-add-service=https

然后安装一些必需的软件包：

# yum update && yum install openssl mod_nss crypto-utils

重要：请注意如果你想使用 OpenSSL 库而不是 NSS（ Network Security Service （ 网络安全服务 ） ）实现 TLS，你可以在上面的命令中用 mod\_ssl 替换 mod\_nss（使用哪一个取决于你，但在这篇文章中我们会使用 NSS，因为它更加安全，比如说，它支持最新的加密标准，比如 PKCS #11）。

如果你使用 mod\_nss，首先要卸载 mod\_ssl，反之如此。

# yum remove mod_ssl

配置 NSS（网络安全服务）

安装完 mod\_nss 之后，会创建默认的配置文件 /etc/httpd/conf.d/nss.conf。你应该确保所有 Listen 和 VirualHost 指令都指向 443 号端口（HTTPS 默认端口）：

nss.conf – 配置文件

Listen 443
VirtualHost _default_:443

然后重启 Apache 并检查是否加载了 mod\_nss 模块：

# apachectl restart
# httpd -M | grep nss

检查 Apache 是否加载 mod\_nss 模块

下一步，在 /etc/httpd/conf.d/nss.conf 配置文件中做以下更改：

1、 指定 NSS 数据库目录。你可以使用默认的目录或者新建一个。本文中我们使用默认的：

NSSCertificateDatabase /etc/httpd/alias

2、 通过保存密码到数据库目录中的 /etc/httpd/nss-db-password.conf 文件来避免每次系统启动时要手动输入密码：

NSSPassPhraseDialog file:/etc/httpd/nss-db-password.conf

其中 /etc/httpd/nss-db-password.conf 只包含以下一行，其中 mypassword 是后面你为 NSS 数据库设置的密码：

internal:mypassword

另外，要设置该文件的权限和属主为 0640 和 root:apache：

# chmod 640 /etc/httpd/nss-db-password.conf
# chgrp apache /etc/httpd/nss-db-password.conf

3、 由于 POODLE SSLv3 漏洞，红帽建议停用 SSL 和 TLSv1.0 之前所有版本的 TLS（更多信息可以查看这里）。

确保 NSSProtocol 指令的每个实例都类似下面一样（如果你没有托管其它虚拟主机，很可能只有一条）：

NSSProtocol TLSv1.0,TLSv1.1

4、 由于这是一个自签名证书，Apache 会拒绝重启，并不会识别为有效发行人。由于这个原因，对于这种特殊情况我们还需要添加：

NSSEnforceValidCerts off

5、 虽然并不是严格要求，为 NSS 数据库设置一个密码同样很重要：

# certutil -W -d /etc/httpd/alias

为 NSS 数据库设置密码

创建一个 Apache SSL 自签名证书

下一步，我们会创建一个自签名证书来让我们的客户机可以识别服务器（请注意这个方法对于生产环境并不是最好的选择；对于生产环境你应该考虑购买第三方可信证书机构验证的证书，例如 DigiCert）。

我们用 genkey 命令为 box1 创建有效期为 365 天的 NSS 兼容证书。完成这一步后：

# genkey --nss --days 365 box1

选择 Next：

创建 Apache SSL 密钥

你可以使用默认的密钥大小（2048），然后再次选择 Next：

选择 Apache SSL 密钥大小

等待系统生成随机比特：

生成随机密钥比特

为了加快速度，会提示你在控制台输入随机字符，正如下面的截图所示。请注意当没有从键盘接收到输入时进度条是如何停止的。然后，会让你选择：

1. 是否发送验证签名请求（CSR）到一个验证机构（CA）：选择 No，因为这是一个自签名证书。
2. 为证书输入信息。

最后，会提示你输入之前给 NSS 证书设置的密码：

# genkey --nss --days 365 box1

Apache NSS 证书密码

需要的话，你可以用以下命令列出现有的证书：

# certutil –L –d /etc/httpd/alias

列出 Apache NSS 证书

然后通过名字删除（如果你真的需要删除的，用你自己的证书名称替换 box1）：

# certutil -d /etc/httpd/alias -D -n "box1"

如果你需要继续进行的话，请继续阅读。

测试 Apache SSL HTTPS 连接

最后，是时候测试到我们服务器的安全连接了。当你用浏览器打开 https://，你会看到著名的信息 “This connection is untrusted”：

检查 Apache SSL 连接

在上面的情况中，你可以点击 添加例外 （ Add Exception ） 然后 确认安全例外 （ Confirm Security Exception ） - 但先不要这么做。让我们首先来看看证书看它的信息是否和我们之前输入的相符（如截图所示）。

要做到这点，点击上面的 视图 （ View... ） -> 详情 （ Details ） 选项卡，当你从列表中选择发行人你应该看到这个：

确认 Apache SSL 证书详情

现在你可以继续，确认例外（限于此次或永久），然后会通过 https 把你带到你 web 服务器的 DocumentRoot 目录，在这里你可以使用你浏览器自带的开发者工具检查连接详情：

在火狐浏览器中，你可以通过在屏幕中右击，然后从上下文菜单中选择 检查元素 （ Inspect Element ） 启动开发者工具，尤其要看“ 网络 （ Network ） ”选项卡：

检查 Apache HTTPS 连接

请注意这和之前显示的在验证过程中输入的信息一致。还有一种方式通过使用命令行工具测试连接：

左图（测试 SSLv3）：

# openssl s_client -connect localhost:443 -ssl3

右图（测试 TLS）：

# openssl s_client -connect localhost:443 -tls1

测试 Apache SSL 和 TLS 连接

参考上面的截图了解更详细信息。

总结

我想你已经知道，使用 HTTPS 会增加会在你站点中输入个人信息的访客的信任（从用户名和密码到任何商业/银行账户信息）。

在那种情况下，你会希望获得由可信验证机构签名的证书，正如我们之前解释的（步骤和设置需要启用例外的证书的步骤相同，发送 CSR 到 CA 然后获得返回的签名证书）；否则，就像我们的例子中一样使用自签名证书即可。

要获取更多关于使用 NSS 的详情，可以参考关于 mod-nss 的在线帮助。如果你有任何疑问或评论，请告诉我们。

via: http://www.tecmint.com/create-apache-https-self-signed-certificate-using-nss/

作者：Gabriel Cánepa 译者：ictlyh 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

根据 Let's Encrypt 官方博客消息，Let's Encrypt 服务将在下周（11 月 16 日）正式对外开放。

Let's Encrypt 项目是由 互联网安全研究小组 （ ISRG，Internet Security Research Group ） 主导并开发的一个新型 数字证书认证机构 （ CA，Certificate Authority ） 。该项目旨在开发一个自由且开放的自动化 CA 套件，并向公众提供相关的证书免费签发服务以降低安全通讯的财务、技术和教育成本。在过去的一年中，互联网安全研究小组拟定了 ACME 协议草案，并首次实现了使用该协议的应用套件：服务端 Boulder 和客户端 letsencrypt。

至于为什么 Let's Encrypt 让我们如此激动，以及 HTTPS 协议如何保护我们的通讯请参考浅谈 HTTPS 和 SSL/TLS 协议的背景与基础。

（题图来自：muylinux.com）

ACME 协议

Let's Encrypt 的诞生离不开 ACME（ 自动证书管理环境 （ Automated Certificate Management Environment ） ）协议的拟定。

说到 ACME 协议，我们不得不提一下传统 CA 的认证方式。Let's Encrypt 服务所签发的证书为 域名认证证书 （ DV，Domain-validated Certificate ） ，签发这类证书需要域名所有者完成以下至少一种 挑战 （ Challenge ） 以证明自己对域名的所有权：

• 验证申请人对域名的 Whois 信息中邮箱的控制权；
• 验证申请人对域名的常见管理员邮箱（如以 admin@、postmaster@ 开头的邮箱等）的控制权；
• 在 DNS 的 TXT 记录中发布一条 CA 提供的字符串；
• 在包含域名的网址中特定路径发布一条 CA 提供的字符串。

不难发现，其中最容易实现自动化的一种操作必然为最后一条，ACME 协议中的 Simple HTTP 认证即是用一种类似的方法对从未签发过任何证书的域名进行认证。该协议要求在访问 http://域名/.well-known/acme-challenge/指定字符串 时返回特定的字符串。

然而实现该协议的客户端 letsencrypt 做了更多——它不仅可以通过 ACME 协议配合服务端 Boulder 的域名进行 独立 （ standalone ） 的认证工作，同时还可以自动配置常见的服务器软件（目前支持 Nginx 和 Apache）以完成认证。

Let's Encrypt 免费证书签发服务

对于大多数网站管理员来讲，想要对自己的 Web 服务器进行加密需要一笔不小的支出进行证书签发并且难以配置。根据早些年 SSL Labs 公布的 2010 年互联网 SSL 调查报告（PDF） 指出超过半数的 Web 服务器没能正确使用 Web 服务器证书，主要的问题有证书不被浏览器信任、证书和域名不匹配、证书过期、证书信任链没有正确配置、使用已知有缺陷的协议和算法等。而且证书过期后的续签和泄漏后的吊销仍需进行繁琐的人工操作。

幸运的是 Let's Encrypt 免费证书签发服务在经历了漫长的开发和测试之后终于来临，在 Let's Encrypt 官方 CA 被广泛信任之前，IdenTrust 的根证书对 Let's Encrypt 的二级 CA 进行了交叉签名使得大部分浏览器已经信任 Let's Encrypt 签发的证书。

使用 letsencrypt

由于当前 Let's Encrypt 官方的证书签发服务还未公开，你只能尝试开发版本。这个版本会签发一个 CA 标识为 happy hacker fake CA 的测试证书，注意这个证书不受信任。

要获取开发版本请直接：

$ git clone https://github.com/letsencrypt/letsencrypt

以下的使用方法摘自 Let's Encrypt 官方网站。

签发证书

letsencrypt 工具可以协助你处理证书请求和验证工作。

自动配置 Web 服务器

下面的操作将会自动帮你将新证书配置到 Nginx 和 Apache 中。

$ letsencrypt run

独立签发证书

下面的操作将会将新证书置于当前目录下。

$ letsencrypt -d example.com auth

续签证书

默认情况下 letsencrypt 工具将协助你跟踪当前证书的有效期限并在需要时自动帮你续签。如果需要手动续签，执行下面的操作。

$ letsencrypt renew --cert-path example-cert.pem

吊销证书

列出当前托管的证书菜单以吊销。

$ letsencrypt revoke

你也可以吊销某一个证书或者属于某个私钥的所有证书。

$ letsencrypt revoke --cert-path example-cert.pem

$ letsencrypt revoke --key-path example-key.pem

Docker 化 letsencrypt

如果你不想让 letsencrypt 自动配置你的 Web 服务器的话，使用 Docker 跑一份独立的版本将是一个不错的选择。你所要做的只是在装有 Docker 的系统中执行：

$ sudo docker run -it --rm -p 443:443 -p 80:80 --name letsencrypt \
            -v "/etc/letsencrypt:/etc/letsencrypt" \
            -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
            quay.io/letsencrypt/letsencrypt:latest auth

你就可以快速的为自己的 Web 服务器签发一个免费而且受信任的 DV 证书啦！

Let's Encrypt 的注意事项

• Let's Encrypt 当前发行的 DV 证书仅能验证域名的所有权，并不能验证其所有者身份；
• Let's Encrypt 不像其他 CA 那样对安全事故有保险赔付；
• Let's Encrypt 目前不提供 Wildcard 证书；
• Let's Encrypt 的有效时间仅为 90 天，逾期需要续签（可自动续签）。

对于 Let's Encrypt 的介绍就到这里，让我们一起目睹这场互联网的安全革命吧。

旨在让每个网站都能使用 HTTPS 加密的非赢利组织 Let’s Encrypt 已经得了 IdenTrust 的交叉签名，这意味着其证书现在已经可以被所有主流的浏览器所信任。从这个里程碑事件开始，访问者访问使用了 Let’s Encrypt 证书的网站不再需要特别配置就可以得到 HTTPS 安全保护了。

Let’s Encrypt 的两个中级证书 Let’s Encrypt Authority X1 和 Let’s Encrypt Authority X2 得到了交叉签名。Web 服务器需要在证书链中配置交叉签名，客户端会自动处理好其它的一切。

你现在可以在此体验一下使用新的交叉签名的中级证书所签发证书的服务器。

越来越多的重要的个人和商业信息在互联网上传递着，对它们的加密需求也越来越迫切。这就是创建 Let’s Encrypt 的目的，这次迈进的一大步将会把安全连接带到 web 世界的每一个角落。

Let’s Encrypt 项目获得了 Mozilla、思科、Akamai、IdenTrust 和 EFF 等组织的支持，由 Linux 基金会托管。它在9月中旬颁发了第一个证书，计划于11月16日向公众开放免费签名服务。

假如你已经完全配好了你的 SSL：使用了强加密算法、禁用了废弃的协议，而且你提供了 100% SHA-2 的证书链。SSL Labs 给了你一个 A+ 评分，shaaaaaaaaaaaaa.com 也没发现你使用了 SHA-1。但是，有些情况下，当你访问你的网站时，Chrome 仍旧会在 URL 栏处显示一个红叉，并且说你的网站提供了 SHA-1 证书，是“ 肯定不安全的 （ affirmatively insecure ） ” 的：

这可能吗？不幸的是，有可能。你的服务器所发送的证书也许并不是你的浏览器所使用的。在迁移到 SHA-2 的过程中不应该是这样的，但是由于某些 CA 糟糕的做法和用户使用了老旧的软件，有时候会出现这样的问题。具体听我一一道来。

背景知识：证书链如何工作

一个 SSL 证书必须被 证书授权中心 （ certificate authority，CA ） 签名才是可信的。在最简单的情况下，网站的证书（ 终端证书 （ end-entity certificate ） ）是由浏览器所信任的 CA 的（ 根证书 （ root certificate ） ）直接签名的。

简单 PKI: 终端证书由根证书直接签名

浏览器校验直接由根证书签名的证书很简单：浏览器在它的根证书库里面查找终端证书的签发者，如果找到，就使用该根证书的公钥来校验终端证书的签名。

然而，终端证书很少会由根证书进行签名。相反的，终端证书是由一个“ 中间证书 （ intermediate certificate ） ”（有时候也称之为 下级 CA （ subordinate CA ） ）进行签名的，而中间证书则由根证书进行签名。

典型的 PKI 是使用一个中间证书

校验一个由中间证书签名的证书是困难的。浏览器不能简单地在它的根证书库中找到签发者，因为该证书并不是由根证书签名的。相反，浏览器需要找到签名该证书的中间证书，需要的话还得迭代这个过程（中间证书也许是由其它的中间证书签名的），直到沿着这个证书链找到根证书。而事实上更复杂，因为也许从终端证书到根证书有几种可能的链路。

让浏览器找到中间证书链的最简单的办法是，让服务器告诉它。这就是为什么当你部署一个 SSL 证书时，不仅仅需要你自己的证书，还需要中间证书。不过，浏览器通常会缓存中间证书，也许会使用一个缓存的证书而不是使用由你的服务器提供的证书。这就是为什么在你全部使用了 SHA-2 之后， Chrome 也许还会显示一个红叉的原因：它并没有使用你的证书链上提供的证书，而是使用了其所缓存的 SHA-1 的证书链。

理论上，这是可以避免的，如果 CA 可以正确操作、用户也运行最新的软件的话。不幸的是，现实并不总是这样，个别情况下已知导致这个问题的原因有两个。

（注意：澄清一下，生成证书链的并不是 Chrome ，而是 Chrome 交由操作系统的加密库构建证书链。加密库在 Windows 上是 CryptoAPI，Linux 上是 NSS。）

问题一：将 SHA-1 中间证书用 SHA-2 重用

当 CA 迁移到 SHA-2 时，它可以通过对已有的公钥用 SHA-2 重新签名，从而重用已有的中间证书，或者也可以生成一个带有新的公钥和 主题名 （ subject name ） 的新中间证书。

两种新的 SHA-2 签名方式

第一种方式是错误的。虽然 CA 可以用已有的中间证书使用 SHA-2 重新签名，但是浏览器也许会缓存着带有旧的 SHA-1 签名的中间证书。如上面解释的，浏览器可以忽略由服务器提供的链证书，即便服务器发送了带有新的 SHA-2 签名的中间证书，客户端依然会使用其所缓存的 SHA-1 中间证书来构建证书链。CryptoAPI 就是这样的。

服务器发送了 SHA-2 证书，浏览器使用了缓存的 SHA-1 证书

而第二个办法就避免了缓存证书链的问题。因为 CA 生成了一个新的中间证书，有新的名字和公钥，浏览器不可能有用 SHA-1 签名的旧版本。这就是为什么 Ballot 118 在 CA/Browser Forum 这样说：

SHA-2 下级证书绝不应该链到 SHA-1 的 CA 下级证书上。

不幸的是，有些 CA 根本没在意这个忠告，比如某个 CA ，StartCom，仍然使用 SHA-1 中间证书签发 SHA-2 终端证书。虽然他们提供了一个 SHA-2 签名的中间证书，但是如果浏览器已经有一个缓存的 SHA-1 版本时就会有问题。

幸运的是，SSLMate 的两个 CA 都正确地从新的 SHA-2 中间证书签发证书，所以，SSLMate 的客户不需要担心这个。

问题二：过期的 NSS 和交叉签名的根证书

有时候根证书自身也由其它的根证书签名，通常这称之为 交叉签名 （ cross-signing ） 。这提供了一个抵达可信根证书的另外一条路径，交叉签名可以让一个不在你的浏览器的可信证书库中的新根证书也可以工作。当浏览器开始信任一个根证书时，交叉签名的证书就不再需要了。然而，和中间证书一样，交叉签名的证书也是可以缓存的，而在 NSS 中一个 bug 会导致 Linux 上的 Chrome 使用缓存的交叉签名的根证书，即使有更短和更新的证书链存在。如果这个缓存的交叉签名证书正好使用 SHA-1，Chrome 就会使用这个有问题的证书链并显示一个红叉，而不管你的服务器是否发送了全都使用 SHA-2 的证书链。

NSS 使用缓存的交叉签名证书构建证书链

这个 bug 在 NSS 3.17.4 中修复，发布于1/28。不幸的是，Debian 更新 NSS 软件包非常缓慢。这个 bug 在2014/12/30 就提交到了 Debian 的 bug tracker 上了，但是直到 5/13 都没在 Debian Unstable 中修复。同时，Debian Stable （Jessie）继续用着 NSS 3.17.2 。Debian 安全团队排除了会通过安全更新修复它，而且看起来包维护者也不像是会快速响应将这个修复加入到即将发布（本文写作时）的 Debian Stable 中。Ubuntu 则不同，将此作为安全问题，在 2/19 给其所有发行版发布了更新包。

不幸的是，CA 不能为使用过期 NSS 的用户做些什么。直到 Debian 为其稳定发行版发布更新的 NSS 包之前，Debian 上的 Chrome 用户会一直看到许多这样的红叉：

或者，如果证书在 2016 年失效的话是这样：

更新：由 SSLMate 的 Andrew Ayer 提供的 NSS 更新包，放到了 2015/9/5 发布的 Debian Jessie 8.2 中。