怎样在服务器上启用 HTTPS [每日前端夜话(0x1A)]

摘要

创建一个 2048 位 RSA 公钥/私钥对。
生成一个嵌入您的公钥的证书签名请求 (CSR)
将 CSR 与证书颁发机构 (CA) 共享以接收最终证书或证书链。
将最终证书安装在非网络可访问的位置，例如 /etc/ssl（Linux 和 Unix）或 IIS 需要它的位置 (Windows)。

此部分使用 openssl 命令行程序（大部分 Linux、BSD 和 Mac OS X 系统均附带此程序）来生成私钥/公钥和 CSR。

我们首先生成一个 2048 位 RSA 密钥对。较短的密钥，如 1024 位，不足以抵御暴力猜测***。较长的密钥，如 4096 位，则有点过度。长远来看，随着计算机处理开销降低，密钥长度会增加。目前 2048 是最佳长度。

用于生成 RSA 密钥对的命令为：

这将生成以下输出：
https://mmbiz.qpic.cn/mmbiz_png/ttJazfuZaRiajKWIyJbfkgruPLo4avyf846kxwQjFEAdo5Qr9JXUW1qdxHoOgibprpx4rL0dzZ91OF7UWwQwz22Q/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

在此步骤中，您将公钥和有关贵组织及网站的信息嵌入到证书签名请求（或 CSR）中。 openssl 命令以交互方式要求您提供所需的元数据。

运行以下命令：

系统将输出以下内容：

为确保 CSR 的有效性，请运行以下命令：

响应结果应如下所示：

对于不同的证书颁发机构 (CA)，需要使用不同的方法将 CSR 发送给他们。这些方法可能包括在其网站上使用表单、以电子邮件或其他方式发送 CSR。一些 CA（或其经销商）甚至可能将其中部分或全部流程自动化（在某些情况下，包括密钥对和 CSR 的生成）。

将 CSR 发送给 CA 并按照他们的说明接收最终证书或证书链。

对于为您的公钥进行证实的服务，不同 CA 的收费将有所不同。

还可以选择将密钥映射到多个 DNS 名称，包括多个独立名称（例如 example.com、www.example.com、example.net 和 www.example.net 的全部）或“通配符”名称（例如 *.example.com）。

例如，某个 CA 目前提供以下价格：

标准：16 美元/年，适用于 example.com 和 www.example.com。
通配符：150 美元/年，适用于 example.com 和 *.example.com。

按这些价格，当您有 9 个以上子域名时，通配符证书比较划算；您也可以只购买一个或多个单名称证书。（例如，如果您有五个以上子域名，在服务器上启用 HTTPS 时，您可能发现通配符证书更方便。）

      Note: 记住，在通配符证书中，通配符只适用于一个 DNS 标签。对 *.example.com 有效的证书将对 foo.example.com 和 bar.example.com 有效，但对于 foo.bar.example.com 无效。

将证书复制到所有前端服务器的非网络可访问位置，例如 /etc/ssl（Linux 和 Unix）或 IIS 需要它们的位置 (Windows)。

在服务器上启用 HTTPS 是确保网页安全的关键一步。

使用 Mozilla 的服务器配置工具来设置服务器以支持 HTTPS。
定期使用 Qualys 便捷的 SSL 服务器测试来测试网站，并确保得分至少为 A 或 A+。

此时，您必须做出关键的操作决定。选择下列其中一项：

给为网络服务器提供内容的每个主机名指定一个独立的 IP 地址。
使用基于名称的虚拟托管。

如果您一直针对每个主机名使用独立的 IP 地址，则可以轻松地让所有客户端支持 HTTP 和 HTTPS。

但是，大多数网站运营商使用基于名称的虚拟托管以节约 IP 地址，另一个原因是这样通常更方便。 Windows XP 上的 IE 和 2.3 版以前的 Android 的问题是，它们不理解服务器名称指示 (SNI)，而这对 HTTPS 基于名称的虚拟托管非常重要。

将来有一天（希望很快），不支持 SNI 的客户端将被现代软件代替。监控请求日志中的 User Agent 字符串，以了解何时已有足够的用户迁移到现代软件。（您可以决定您的阈值；可能是 < 5%，或 < 1%。）

如果您的服务器上还没有 HTTPS 服务，请立即启用（无需将 HTTP 重定向到 HTTPS；参见下文）。配置网络服务器以使用您购买并安装的证书。您可能发现 Mozilla 便捷的配置生成器很有用。

如果您有许多主机名/子域名，它们每个都需要使用正确的证书。

    Caution: 如果您已完成上述步骤，但您使用 HTTPS 仅仅是为了将客户端重定向回 HTTP，那么，请马上停止这么做。参考下一部分以确保 HTTPS 和 HTTP 顺畅工作。   Note: 最终，您应将 HTTP 请求重定向到 HTTPS 并使用 HTTP 严格传输安全 (HSTS)。不过，现在不是向这种做法进行迁移的合适阶段；请参考“将 HTTP 重定向到 HTTPS”和“打开严格传输安全和安全 Cookie”。

现在，以及您网站的整个生命周期中，使用 Qualys 便捷的 SSL 服务器测试来检查您的 HTTPS 配置。您的网站得分应为 A 或 A+；将导致等级较低的任何因素均视为错误。（今天的 A 在明天会变成 B，因为针对算法和协议的***始终在改进！）

由于您的网站同时运行 HTTP 和 HTTPS，不管哪种协议，都应当尽可能顺畅运行。一个重要的因素是对站内链接使用相对网址。

确保站内网址和外部网址与协议无关；即确保使用相对路径或省去协议，例如 //example.com/something.js。

当您通过 HTTPS 提供一个包括 HTTP 资源的页面（称为混合内容）时会出现问题。浏览器将警告用户，已失去 HTTPS 的全部能力。事实上，如果是主动混合内容（脚本、插件、CSS、iframe），则浏览器通常根本不会加载或执行此内容，从而导致页面残缺。

     Note: 在 HTTP 页面中包括 HTTPS 资源完全没问题。

此外，当您链接到您网站中的其他页面时，用户可能从 HTTPS 降级为 HTTP。

当您的页面包括了使用 http:// 架构的完全限定站内网址时，会出现这些问题。

不建议的做法 — 我们不建议使用完全限定站内网址。

换句话说，使站内网址尽可能是相对地址：协议相对（省去协议，以 //example.com 开头）或主机相对（以相对路径开头，例如 /jquery.js）。

建议做法 — 我们建议您使用协议相对站内网址。

建议做法 — 我们建议您使用相对站内网址。

通过脚本实现，而不是手动操作。如果网站内容在数据库中，则在数据库的开发副本中测试您的脚本。如果网站内容由简单文件组成，则要在文件的开发副本中测试您的脚本。像平常一样，只有在更改通过 QA 后，才会将更改推送到生产平台中。可以使用 Bram van Damme 的脚本或类似脚本来检测网站中的混合内容。

在链接到其他网站（而不是包括其他网站的资源）时，请勿更改协议，因为您不能控制这些网站的运行方式。

     Success: 为确保大型网站的迁移更顺利，我们建议采用协议相对网址。如果您还不确定是否能够完全部署 HTTPS，则强制网站的所有子资源使用 HTTPS 可能会弄巧成拙。可能会有一段时间，您对 HTTPS 觉得新奇，并且 HTTP 网站仍必须像往常一样运行。但从长远看，您将完成迁移并锁定 HTTPS（请参考接下来两个部分）。

如果网站依赖第三方（例如 CDN、jquery.com）提供的脚本、图像或其他资源，则有两个选择：

对这些资源使用协议相对网址。如果该第三方不提供 HTTPS，请求他们提供。大多数已经提供，包括 jquery.com。
从您控制的并且同时提供 HTTP 和 HTTPS 的服务器上提供资源。这通常是个好点子，因为您可以更好地控制网站的外观、性能和安全。此外，您不必信任第三方，尽管他们总是很不错。
```
Note: 请记住，您还需要更改样式表、JavaScript、重定向规则、<link> 标记和 CSP 声明中的站内网址，而不仅是 HTML 页面。
```
您需要在页面的最前面放一个规范链接，以告诉搜索引擎 HTTPS 是访问您网站的最佳方法。

在页面中设置 <link rel="canonical" href="https://…"/> 标记。这样可帮助搜索引擎确定访问您网站的最佳方法。

此时，您已准备好“锁定”使用 HTTPS。

使用 HTTP 严格传输安全 (HSTS) 来避免 301 重定向产生的开销。
始终在 Cookie 上设置安全标记。

首先，使用严格传输安全来告诉客户端，它们始终应通过 HTTPS 来连接您的服务器，即使在访问 http:// 引用时也是如此。

这样可挫败 SSL 剥离之类的***，还能避免我们在将 HTTP 重定向到 HTTPS时启用的 301 redirect 产生的往返开销。

      Note: 如果您的网站在其传输层安全协议 (TLS) 配置中出现过错误（例如过期证书），则已将您的网站注明为已知 HSTS 主机的客户端可能出现硬故障。通过此方式显式设计 HSTS 可确保网络***者无法欺骗客户端访问没有 HTTPS 的网站。在确认您的网站运营足够可靠之前，不要启用 HSTS，以避免部署 HTTPS 时总是出现证书验证错误。

通过设置 Strict-Transport-Security 标头来打开 HTTP 严格传输安全 (HSTS)。OWASP 的 HSTS 页面有说明链接，提供了针对各种服务器软件的说明。

大多数网络服务器提供相似的功能来添加自定义标头。

       Note: max-age 的计算单位为秒。您可以从较小的值开始，并随着您越来越熟练自如地运营纯 HTTPS 网站而逐步增加 max-age。

还要务必确保客户端从不通过 HTTP 发送 Cookie（例如用于身份验证或网站偏好）。例如，如果用户的身份验证 Cookie 将在明文中暴露，则其整个会话的安全保障将被破坏 — 即使其他的一切都正确无误！

因此，更改您的网络应用，以便始终在其设置的 Cookie 上设置安全标记。此 OWASP 网页解释了如何在多个应用框架中设置安全标记。每个应用框架都采用一种方法来设置此标记。

大多数网络服务器都提供一种简单的重定向功能。使用 301 (Moved Permanently) 来告诉搜索引擎和浏览器，此 HTTPS 版本是规范的，并将用户从 HTTP 重定向到网站的 HTTPS 版本。

对于从 HTTP 迁移到 HTTPS，许多开发者有着合情合理的顾虑。Google 网站站长团队提供了一些非常好的指导【https://plus.google.com/+GoogleWebmasters/posts/eYmUYvNNT5J】。

Google 使用 HTTPS 用作肯定性的搜索质量指标【https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html】。Google 还发布一个指南，说明在维护其搜索排名时如何传输、移动或迁移您的网站。

Bing 也发布了网站站长指南。

当内容和应用层优化得当时（请参考 Steve Souders 的论著以获取很好的建议），相对于应用的总体开销而言，其余的传输层安全协议 (TLS) 性能问题一般都是小问题。此外，您可以减少和分摊那些开销。（如需 TLS 优化建议和一般建议，请参考 IlyaGrigorik 撰写的高性能浏览器网络。）另请参考 Ivan Ristic 的 OpenSSL 手册和 SSL 和 TLS 的防弹衣。

在某些情况下，TLS 可以提高性能，主要是可以采用 HTTP/2 所带来的结果。 Chris Palmer 在 Chrome 开发峰会 2014 上做过一个演讲，讨论 HTTPS 和 HTTP/2 的性能。

当用户从您的 HTTPS 网站链接到其他 HTTP 网站时，User Agent 不会发送引用站点标头。如果这是个问题，有多种方法可解决：

其他网站应迁移到 HTTPS。如果被引用网站可以完成本指南中的在服务器上启用 HTTPS 部分，则可以将您网站中指向他们网站的链接从 http:// 更改为 https://，或可以使用协议相对链接。
为解决引用站点标头的各种问题，可使用新的引用站点政策标准。

由于各搜索引擎正在迁移到 HTTPS，将来，当您迁移到 HTTPS 时，可能会看到更多的引用站点标头。

    Caution: 根据 HTTP RFC，如果引用页面是通过安全协议传输的，则客户端不能在（非安全）HTTP 请求中包括引用站点标头字段。

通过展示广告来赚钱的网站运营商希望确保迁移到 HTTPS 不会降低广告曝光量。但是，由于混合内容的安全问题，HTTP <iframe> 在 HTTPS 页面中不起作用。这里就存在一个棘手的集体行动问题：在广告商通过 HTTPS 发布广告之前，网站运营商无法在不损失广告收入的情况下迁移到 HTTPS；但是在网站运营商迁移到 HTTPS 之前，广告商没有动力来通过 HTTPS 发布广告。

广告商至少应通过 HTTPS 提供广告服务（例如完成本页面中的“在服务器上启用 HTTPS”部分）。许多广告商已经这样做了。您应当请求完全不提供 HTTPS 的广告商至少开始提供 HTTPS。

摘要

更多相关文章

随机推荐