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

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

让我们加密提供免费 SSL 证书。与其他付费证书相比,是否存在缺点?例如AWS 证书管理器

答案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 以外的其他环境中使用证书,那么传统的购买证书方式特别有用。

答案2

从纯技术角度来看:

  • 事实上,证书的有效期只有 3 个月。根据变更管理程序和基础设施,维护证书可能会很麻烦。
  • Let's Encrypt 证书的用途有限。您不能将其用于电子邮件、代码签名或时间戳。
    请检查: openssl x509 -in cert.pem -noout -text

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

从最终用户的角度来看:

答案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 不兼容。

此外,有些人认为电动汽车是有害的,比如这篇博文(https://stripe.ian.sh/):

例如,詹姆斯·伯顿 (James Burton) 最近为他的公司“身份验证”申请了 EV 证书。不幸的是,用户根本没有能力处理这些实体的细微差别,这为网络钓鱼创造了一个重​​要的载体。

一个典型的例子就是 sslstrip。使用合法购买的证书的同形异义词网站是现实世界中的攻击,而 EV 目前无法提供足够的防御。

答案4

有两组缺点值得考虑。

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

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

Let's Encrypt 证书的有效期为 90 天,这意味着您需要自动化,因为没有人有时间这样做。事实上,这是该服务的目的 - 引导人们自动化这项基本工作,而不是在自动化许多更困难的任务时反常地手动完成。但是,如果您因任何原因无法实现自动化,则会产生负面影响 - 如果您拥有阻碍自动化的工具、设备或任何事物,请在成本规划中将任何商业 SSL 证书成本视为这些工具/设备/任何事物的持续成本的一部分。相反,无需购买商业证书所带来的节省可以抵消新工具/设备/等自动化定价(无论是否使用 Let's Encrypt)

Let's Encrypt 控制自动化证明可能不符合贵公司的规则。例如,如果您的员工被允许重新配置 Apache,但不应获得公司域名的 SSL 证书,那么 Let's Encrypt 就不合适。请注意,在这种情况下,不使用它们是错误的选择 (TM),您应该使用 CAA 明确禁用您域的 Let's Encrypt。

如果 Let's Encrypt 的政策拒绝了你,唯一的“上诉”就是在其公共论坛上提问,并希望他们的一名员工能够提供一条出路。例如,如果你的站点有一个 DNS 名称,他们的系统认为它与某些知名资产(如大银行或谷歌)“容易混淆”,那么这种情况就可能发生。出于合理的原因,每个公共 CA 在这方面的具体政策都不向公众开放,因此你可能只有在请求 Let's Encrypt 证书并收到“政策禁止...”的回复时,才会意识到你无法获得该证书。

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

如今,主流网络浏览器通过 ISRG(提供 Let's Encrypt 服务的慈善机构)信任 Let's Encrypt 证书,但较旧的系统通过 IdenTrust 信任 Let's Encrypt,IdenTrust 是一个相对不为人知的证书颁发机构,控制着“DST Root CA X3”。这可以满足大多数人的需求,但它并不是世界上最受信任的根。例如,被遗弃的 Nintendo WiiU 游戏机有一个网络浏览器,显然 Nintendo 不会为 WiiU 提供更新,因此该浏览器被遗弃,它不信任 Let's Encrypt。

Let's Encrypt 只为 Web PKI(使用 SSL/TLS 协议的 Internet 名称服务器)颁发证书。显然,这包括 Web、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 是做出此决定的明智方法。

相关内容