Let's Encrypt 是一个证书颁发机构，它们与市场上任何其他现有（和更大）的证书颁发机构具有或多或少相同的特权和权力。

截至今天，使用 Let's Encrypt 证书的主要缺点是兼容性。这是任何新的CA在接近市场时都会面临的问题。

为了使证书受信任，它必须由属于受信任 CA 的证书签名。为了获得信任，CA 必须将签名证书捆绑在浏览器/操作系统中。今天进入市场的 CA，假设它们从第 0 天开始就被批准用于每个浏览器/操作系统的根证书程序（这是不可能的），将包含在各种浏览器/操作系统的当前版本中。但是，它们将无法包含在较旧的（和已发布的）版本中。

换句话说，如果 CA Foo 在第 0 天加入根程序，此时 Google Chrome 版本为 48，Max OSX 为 10.7，则 Foo CA 将不会包含（和信任）在 48 或 Mac OSX 之前的任何版本的 Chrome 中在 10.7 之前。您不能追溯信任 CA。

为了限制兼容性问题，Let's Encrypt 获得了由另一个旧 CA (IdenTrust) 交叉签名的根证书。这意味着不包含 LE 根证书的客户端仍然可以回退到 IdenTrust 并且证书将被信任......在理想世界中。事实上，似乎有多种情况当前没有发生这种情况（Java、Windows XP、iTunes 和其他环境）。因此，这是使用 Let's Encrypt 证书的主要缺点：与其他较老的竞争对手相比，兼容性降低。

除了兼容性之外，其他可能的缺点本质上与 Let's Encrypt 的发行策略及其业务决策有关。与任何其他服务一样，它们可能不提供您需要的某些功能。

下面是 Let's Encrypt 与其他 CA 相比的一些显着差异（我还写了一篇关于它们的文章）：

• LE 目前不颁发通配符证书（他们将于2018 年 1 月开始颁发通配符证书）LE现在使用更新的 ACMEv2 协议颁发通配符证书
• LE 证书的有效期为 90 天
• LE 只颁发域或 DNS 验证的证书（他们不打算颁发 OV 或 EV，因此他们只验证所有权而不是请求证书的实体）
• 当前的 非常严格 速率限制 ^† （他们会在接近公测结束的同时继续放宽限制）

以上几点不一定是缺点。但是，它们是可能无法满足您的特定要求的业务决策，在这种情况下，与其他替代方案相比，它们将代表缺点。

^†主要速率限制是每个注册域每周 20 个证书。但是，这并不限制您每周可以发出的续订次数。

使用 Let's Encrypt 的原因可能是价格。这些证书将是免费的。

但我看到非小型网站的一个可能缺点。Big CA 提供通配符证书、扩展验证证书，它们有一些优势（从我的角度来看）。此外，这个程序是针对 web 服务器的，但是如果你有一些应用程序服务器或者你想保护邮件服务器怎么办？

更新：目前可以请求证书，而不是绑定到 Web 服务器。所以我的最后一个论点不再有效。这是使用此选项的一些示例：

./letsencrypt-auto certonly --standalone -d example.com

更新 2：从 2018 年 1 月起，Let's Encrypt 将开始颁发通配符证书

通配符证书将于 2018 年 1 月推出

2017 年 7 月 6 日 • Josh Aas，ISRG 执行董事

Let's Encrypt 将于 2018 年 1 月开始颁发通配符证书。通配符证书是一项普遍要求的功能，我们知道在某些用例中它们使 HTTPS 部署更容易。我们希望提供通配符将有助于加速 Web 向 100% HTTPS 迈进。

因此，再有一个论点不再有效。

使大公司不考虑 Let's Encrypt 的一个缺点是连接到该站点的访问者不能确定它是托管该站点的实际公司。

这是因为 Let's Encrypt 为没有身份验证（个人或公司）的域免费颁发证书（Let's Encrypt 仅提供域验证）。

编辑添加： 出于安全传输的目的，这不是一个大问题。但是，如果您想验证是否是您正在寻找的实际公司拥有该域名，则whois查找可能还不够。2 类或 3 类或 EV 证书的优点是公司和域由证书颁发机构验证。

使用 Let'encrypt 的另一个问题是，在企业场景中，我们还需要为负载均衡器和 CDN 提供商安装证书。并非所有 CDN 提供商都有 API 可以自动更改这一点。同样到目前为止，让我们加密的有效期为 90 天，这使此过程更加复杂。