除了 Let's Encrypt 的免费 SSL 之外，还有其他理由使用 SSL 证书吗？

Question

Let's Encrypt提供免费的 SSL 证书。与其他付费证书（例如AWS Certificate Manager）相比，是否有任何缺点？

Answer 1

证书有效期

安全

寿命越短越好。仅仅因为撤销主要是理论上的，实际上不能依赖它（公共 PKI 生态系统的一大弱点）。

管理

没有自动化：更长的使用寿命更方便。如果您出于某种原因无法自动化证书管理，那么 LE 可能不可行
。 自动化：寿命无关紧要。

最终用户印象

最终用户不太可能以某种方式有任何想法。

验证级别

安全

Letsencrypt 仅提供 DV 级别的验证。
购买证书，无论付出什么代价都可以得到（从 DV 开始，与 LE 具有相同的断言级别）。

DV = 仅验证域名控制。
OV = 所有者实体（组织）信息被另外验证。
EV = 更彻底的 OV 版本，传统上被授予“绿条”（但“绿条”似乎很快就会消失）。

管理

使用 LE 时，您所做的工作是设置必要的自动化（在此上下文中，用于证明域控制）。有多少工作将取决于您的环境。

购买证书时，DV/OV/EV 级别将定义获得证书所需的手动工作量。对于 DV，它通常归结为通过向导支付和复制/粘贴某些内容或单击某些内容，对于 OV 和 EV，您几乎可以指望需要单独联系以执行其他步骤来确认您的身份。

最终用户印象

最终用户可能会认出当前的 EV“绿条”（即将消失），但他们实际上并不倾向于查看证书内容。
但是，从理论上讲，使用声明有关控制实体的信息的证书显然更有帮助。但是浏览器（或其他客户端应用程序）需要开始以有用的方式实际显示这一点，然后才能对典型用户产生任何影响。

安装

安全

可能会以暴露私钥或类似的方式错误地做事。使用 LE，提供的工具是围绕合理的实践设置的。
对于知道自己在做什么的人，手动步骤显然也可以安全地完成。

管理

LE 非常希望所有流程都自动化，他们的服务完全基于 API，而且生命周期短也反映了一切都以自动化为中心。

购买证书时，即使 CA 为普通客户提供 API（此时并不是真正的规范），也很难正确地自动化除 DV 之外的任何东西，并且使用 DV，您支付的费用与 LE 提供的东西基本相同。
如果您要达到 OV 或 EV 水平，您可能只能部分自动化该过程。

最终用户印象

如果安装正确完成，最终用户显然不知道它是如何完成的。在自动化过程中，搞砸事情（例如，忘记更新或更新时安装错误）的可能性较小。

总体

如果您需要 OV/EV 证书、不自动化证书管理或想要在 HTTPS 以外的其他上下文中使用证书，则购买证书的传统方式特别有用。

Answer 2

从纯技术角度：

• 证书的有效期仅为 3 个月。根据您的变更管理程序和基础设施，维护起来可能很麻烦。
• Let's Encrypt 证书的用途是有限的。您不能将它们用于您的电子邮件、代码签名或时间戳。
  检查： openssl x509 -in cert.pem -noout -text

  X509v3 扩展密钥用法：
  TLS Web 服务器身份验证、TLS Web 客户端身份验证

从最终用户的角度：

• 缺少扩展验证意味着在某些网络浏览器中“没有绿条”。
  • 但是，Chrome 将在 2018 年 9 月逐步淘汰绿色条，取而代之的是一个小锁图标，最终没有特殊指示器，而只会显示不安全页面的警告。

Answer 3

我想在这里为反对 Let's Encrypt 的论点提供一些反驳点。

寿命短

是的，它们的生命周期很短，如常见问题解答中所述：https : //letsencrypt.org/2015/11/09/why-90-days.html引用该页面：

1. 它们限制了密钥泄露和误发造成的损害。被盗密钥和错误颁发的证书有效期较短。

2. 他们鼓励自动化，这对于易用性来说绝对是必不可少的。如果我们要将整个 Web 迁移到 HTTPS，我们不能继续期望系统管理员手动处理续订。一旦发行和续订自动化，较短的生命周期不会比较长的生命周期更方便。

缺乏电动汽车

没有电动汽车支持计划。推理（来自https://community.letsencrypt.org/t/plans-for-extended-validation/409）是：

我们预计 Let's Encrypt 不会支持 EV，因为 EV 过程总是需要人工，这需要有人付钱。我们的模式是免费颁发证书，这需要一个似乎与 EV 不兼容的级别自动化。

此外，还有一些人认为 EV 是有害的，比如这篇博文（https://stripe.ian.sh/）：

例如，James Burton 最近为其公司“身份验证”获得了 EV 证书。不幸的是，用户根本没有能力处理这些实体的细微差别，这为网络钓鱼创造了一个重​​要的载体。

一个经典的现实世界示例是 sslstrip。具有合法购买证书的同形异义词网站是一种现实世界的攻击，目前 EV 无法提供足够的防御。

Answer 4

有两组缺点值得考虑。

1. 使用 Let's Encrypt 服务的缺点

Let's Encrypt 要求确切名称或（子）域（如果您请求通配符）存在于公共 Internet DNS 中。即使您证明了对 example.com 的控制权，Let's Encrypt 也不会在没有在公共 DNS 中看到的情况下为 some.other.name.in.example.com 颁发证书。命名的机器不需要有公共地址记录，它们可以被防火墙关闭，甚至物理断开，但公共 DNS 名称需要存在。

让我们加密 90 天的证书生命周期意味着您需要自动化，因为没有人有时间这样做。这实际上是该服务的意图 - 引导人们将这项基本工作自动化，而不是在他们自动化许多更艰巨的任务的同时手动进行。但是，如果您因任何原因无法实现自动化，那就是负面的——如果您有工具、设备或任何阻碍自动化的东西，请考虑将任何商业 SSL 证书成本作为这些工具/设备/任何成本规划中的持续成本的一部分。相反，由于不需要购买商业证书来自动执行此操作的新工具/设备/等的定价（无论是否使用 Let's Encrypt），从而抵消了节省的成本

Let's Encrypt 控制自动化证明可能不适合您组织的规则。例如，如果您的员工可以重新配置 Apache，但不应获得公司域名的 SSL 证书，那么 Let's Encrypt 就不合适了。请注意，在这种情况下，只是不使用它们是错误的事情（TM），您应该使用 CAA 为您的域明确禁用 Let's Encrypt。

如果 Let's Encrypt 政策拒绝您，唯一的“上诉法院”就是在其公共论坛上提问，并希望他们的一名员工能够提供前进的道路。例如，如果您的站点的 DNS 名称被他们的系统判定为与某些著名的资产（如大银行或 Google）“令人困惑地相似”，则可能会发生这种情况。出于合理的原因，每个公共 CA 在这方面的确切政策并未接受公众审查，因此您可能只会在请求时才意识到无法拥有 Let's Encrypt 证书并获得“政策禁止...”响应。

2. Let's Encrypt 证书本身的缺点

如今，主要网络浏览器通过 ISRG（提供 Let's Encrypt 服务的慈善机构）信任 Let's Encrypt 证书，但较旧的系统通过 IdenTrust 信任 Let's Encrypt，IdenTrust 是一个相对模糊的证书颁发机构，控制“DST Root CA X3”。这可以为大多数人完成工作，但它并不是世界上最广泛信任的根。例如，废弃的任天堂 WiiU 控制台有一个网络浏览器，显然任天堂不会为 WiiU 提供更新，因此浏览器被废弃，它不信任 Let's Encrypt。

Let's Encrypt 只为 Web PKI 颁发证书 - 具有使用 SSL/TLS 协议的 Internet 名称的服务器。很明显，这就是网络，还有你的 IMAP、SMTP、某些类型的 VPN 服务器、许多东西，但不是所有东西。特别是 Let's Encrypt 根本不提供 S/MIME 证书（一种在静止状态下加密电子邮件的方法，而不仅仅是在传输时加密）也不提供代码签名或文档签名。如果您想要证书的“一站式服务”，这可能是不使用 Let's Encrypt 的足够理由。

即使在 Web PKI 中，Let's Encrypt 也仅提供“DV”证书，这意味着证书中不会提及除 FQDN 之外的有关您或您的组织的任何详细信息。即使您将它们写入 CSR，它们也会被丢弃。这可能是某些专业应用程序的障碍。

Let's Encrypt 自动化意味着即使没有其他原因导致您无法拥有某些东西，您也会完全受到自动化所允许的限制。新类型的公钥、新的 X.509 扩展和其他添加必须由 Let's Encrypt 在他们自己的时间线上明确启用，当然，尽管欢迎捐赠，但你不能只提供额外费用来获得你想要的功能。

尽管如此，对于几乎所有人来说，几乎总是，Let's Encrypt 是将证书以即发即忘的方式放置在 TLS 服务器上的不错的首选。首先假设您将使用 Let's Encrypt 是做出此决定的明智方法。

Answer 5

除非你需要一个证书不是网络上的其他东西，有没有真正的缺点，但肯定察觉的。尽管这些问题只是被察觉到，但作为网站的所有者，您可能别无选择，只能解决这些问题（如果商业利益禁止显示中指）。

就目前而言，最大的一个缺点是，您的网站将显示为有些低劣，可能很危险，因为它没有其他一些网站所拥有的漂亮的绿色徽章。那个徽章是什么意思？真的没什么。但它确实表明您的网站是“安全的”（有些浏览器甚至使用这个确切的词）。唉，用户是人，人是愚蠢的。一个或另一个会认为您的网站不值得信赖（不了解任何含义），只是因为浏览器没有说它是安全的。

如果忽略这些客户/访客是一个有效的可能性，没问题。如果你在商业上负担不起，你将不得不花钱。没有其他选择。

另一个感知到的问题是关于证书生命周期的问题。但这实际上是优势，而不是劣势。更短的有效性意味着证书必须更频繁地更新，服务器端和客户端，好吧。
至于服务器端，这发生在cron工作中，所以它实际上比平时更省事，更可靠。您无法忘记，无法迟到，无法不小心做错事，无需使用管理帐户登录（......不止一次）。在客户端，那又怎样。浏览器一直在更新证书，这没什么大不了的。用户甚至不知道它发生了。有非常轻微更多的流量每3个月更新，而不是每2年的时候是有，但严重...那个 不是问题。

Answer 6

我将添加一个迫使我的雇主部分远离 Lets Encrypt 的问题：API 速率限制。由于生命周期短且缺乏通配符支持，在正常的自动化操作（自动更新等）期间很容易接近速率限制。尝试添加新的子域可能会超过速率限制，一旦达到，LE 无法手动覆盖限制。如果您不备份旧证书（谁会在像 LE envisions 这样的自动化云类型微服务环境中这样做？）所有受影响的站点都将脱机，因为 LE 不会重新颁发证书。

当我们意识到发生了什么时，有那么一刻“哦$#！#”紧接着是紧急的商业证书申请，只是为了让生产站点重新上线。一种具有更合理的 1 年寿命。在 LE 实现适当的通配符支持之前（甚至那时），我们将对他们的产品非常谨慎。

Tl; dr：LE 通配符 + API 限制使管理比“我的个人主页”更复杂的东西出乎意料地具有挑战性，并在此过程中促进了糟糕的安全实践。