为什么要为SSL证书付费？
对于大多数用途，没有充分的理由为此付费。
有关异常的摘要，请参见底部。
让我们退后一步，解释证书的用途以及大致的操作方法。
所谓的“证书”通常由两个链接部分组成：
- 适当的证书 ，其中包含一个公共密钥和一些标识（例如域名）。
- 的私有密钥，它允许所述保持器（并且只有保持器），以在它们可以使用上述证书进行验证这样的方式进行数字签名的消息。
如果您想要的证书yourdomain.com，则：
- 创建一个私有/公共密钥对，并保留私有部分。
- 要求可信赖的第三方（“ CrediCorp”）
yourdomain.com使用您的公共密钥创建证书。
- 向您控制的CrediCorp证明
yourdomain.com。
- 将私钥和获得的证书放在服务器上，然后配置Web服务器以使用它们。
然后，如果Alice访问yourdomain.com，她的浏览器将从您的Web服务器获取证书以及由您的私钥签名的消息。然后，她的浏览器检查了三件事：
- 签名的消息可以通过您的证书进行验证（证明该消息已由仅
yourdomain.com应具有的相应私钥签名）。
- 证书的域是浏览器试图访问的域（
yourdomain.com）。
- 该证书来自CrediCorp。
这三件事的结合保证了爱丽丝实际上是在yourdomain.com和她说话，而不是冒充其他人... 只要爱丽丝信任CrediCorp。
（随后还进行了一些加密伏都教舞，以将这种真实性转变为机密性。）
如何不翘信任CrediCorp？
这才是真正的症结所在。简而言之，CrediCorp在某个时候说：“嘿，我们要制作证书”。在遵循许多规则付出了很多努力之后，他们设法说服了某些人说CrediCorp确实是值得信赖的，并且他们只会正确地颁发证书。
特别是，他们设法说服了Firefox等制造商。结果，CrediCorp进入了Firefox的A列表，并且默认情况下Firefox信任它们的证书。所以说真的，爱丽丝（Alice）信任Firefox，Firefox信任CrediCorp，而CrediCorp（在验证后）信任您（声称已控制您）yourdomain.com。几乎就像一条链子。
但是，Firefox不仅仅信任CrediCorp为其颁发证书yourdomain.com，它还信任任何域的CrediCorp证书。Firefox 还信任任何域的ShabbyCorp。
这有后果。如果有人设法说服ShabbyCorp对其进行控制yourdomain.com（因为ShabbyCorp不够彻底），那么他们可以yourdomain.com使用相应的私钥获取ShabbyCorp证书。有了该证书，他们就可以模拟您的Web服务器。毕竟，他们拥有yourdomain.comFirefox信任的证书（加密钥）！
CrediCorp和ShabbyCorp简称为证书颁发机构（CA）。在现实世界中，ComodoSSL和Let's Encrypt是CA的示例。但是还有更多。截至发稿时，火狐信任的CA 154。
哇 但这如何回答我的问题？
我很明白了...
就是这个 我上面概述的机制适用于所有证书。如果您的网站拥有正确的，受信任的证书，它将可以使用。品牌A证书与品牌B证书之间没有什么特别之处。它们都受相同的CA要求和相同的加密数学的约束。
即使您更喜欢CrediCorp（因为您知道，它们听起来更值得信赖），但使用它们并不会真正帮助您。如果攻击者可以说服ShabbyCorp为您的站点提供证书，则无论您从何处获得证书，攻击者都可以使用该证书来模拟您的站点。
只要Firefox信任ShabbyCorp，访问者就不会看到其中的区别。（是的，访问者可以拉出证书，然后从那里进行挖掘，看看是谁颁发的。但是，是谁做的？）就伪造证书而言，这使整个系统与150多个CA中最弱的一个一样脆弱。为什么会这样，这很可怕，这可能是人们对整个方案的最大批评。尽管如此，这就是我们所坚持的。
重点是，如果您不信任CA颁发“好”证书，那么将证书移到其他位置不会有太大帮助。
糟糕，一切都注定了。没有警告？
Weeeelllll ...
让我们从扼杀我在上一节中提出的观点开始。如今，它可以锁定您的域名，只是你选择的CA的使用DNS-CAA。假设您确实信任Comodo，并且不信任其他CA，则可以请求Comodo以外的所有CA不为您的域颁发证书。理论上。（因为浏览器不检查DNS-CAA，而仅通过发布CA进行检查。因此，受感染的CA可以忽略此保护措施。）
如果您愿意解决这个麻烦，那么问题就变成了：让我们加密实际上不那么值得信赖吗？还是不太安全？诚信是一项艰巨的任务，您如何量化呢？我只能说，在我看来， Let's Encrypt与其他CA一样值得信赖。至于其验证的安全性，它们与商业CA非常相似（无论如何对于DV证书）。另请参阅此问题。
物有所值：该站点所属的StackExchange网络当前使用“让我们加密”证书。大多数人永远不会注意到这一点，如果他们这样做了，我将真心地怀疑这对他们是否有意义。
为了使证书有意义，颁发证书的CA必须受到软件供应商的信任，否则该证书将无用。我以Firefox为例，但实际上您希望CA至少受Firefox，Chrome，Windows，Mac OS X，iOS和Android的当前版本和较旧版本的信任。以及数十个较小的参与者。所有这些实体都信任值得考虑的CA（包括ComodoSSL和Let's Encrypt）。
如果CA行为不当或被证明不可信，它将很快从各种信任库中删除，从而足以破坏证书所有者的日子。我知道的两个著名的例子是DigiNotar和StartCom / WoSign（查看文章，它们提供了有关信任动态的有趣见解！）。因此，如果您认为Let's Encrypt会搞砸了，或者由于其他原因而被放弃，则不使用它们会阻止您陷入该特定后果。
证书使用了一些加密数学魔术 ; 问题是哪种 加密数学魔术？如果是弱魔法怎么办？这实际上是一个真正的问题，而且CA也已显示出在升级此问题上的脚步。幸运的是，浏览器供应商通过在此处设置接受证书的下限来弥补这一不足。例如，使用RSA-1024或SHA-1的证书现在已被大多数浏览器拒绝，因此在实践中可用的任何证书都不会使用这些已弃用的加密原语。结果是，任何CA（包括Let's Encrypt）都很难在这方面感到失望。
在此之前，我或多或少说过所有证书都是一样创建的。我撒谎，他们没有。特别是，到目前为止，我所讨论的是“ 域验证（DV）证书”，这是大多数网站使用的证书。它们可以确定您的浏览器实际上正在与它在URL栏中显示的域进行对话。也有“组织验证（OV）”和“ 扩展验证（EV）”证书，它们需要CA进行更为详尽的检查。特别是，somebank.com如果您确实可以证明自己是 SomeBank，Inc .，那么您应该只能获得/ SomeBank Inc. 的EV证书。
EV证书的获取成本要高得多（据估算：每年数百欧元/美元），并且可能会在浏览器中通过绿色URL栏或挂锁来奖励EV证书，并可能显示“ SomeBank，Inc.”。也一样 与DV证书相反，它们还提供了有关网站可能实际属于谁的一些信息。好的方面是，它们看起来更合法。令人失望的是，用户很少关注他们，因此其有效性受到限制。
拥有伪造的DV证书的攻击者仍然可以假冒该站点，只是没有EV证书可能提供的额外视觉线索，用户通常不会注意到这些区别。相反，可能会获得具有误导性的EV证书，从而使网络钓鱼更加容易。结果，Chrome和Firefox都会放弃对EV证书的视觉认可，有些人认为它们将完全消失。
如果您是银行，现在可能仍需要EV证书。否则，不会那么多。但是，如果您确实需要EV，那么“加密”就不适合您，因为他们根本不提供EV证书。
证书仅在有限的时间内有效。典型的商业CA证书的有效期通常为一年，但是我看到的时间从三个月到三年不等。让我们加密证书的有效期为90天，处于该范围的短边范围内，因此您需要经常更新它们。对于“让我们加密用户”来说，这通常是自动进行的，因此每60天更换一次证书。
实际上，能够使用广泛可用的软件进行自动续签实际上比每年的证书到期更令人愉快。我在CA的登录名是什么？又如何工作？习惯上，大多数小型站点似乎都以商业CA结尾。
以前，我称令人恐惧的是，我们所有人都必须信任这么多的CA。但是，从从我们的信任库中删除单个证书颁发机构对用户的影响有限的意义上来说，拥有多个证书颁发机构也是一个优势。特别是，驱逐一个CA仅会影响该CA颁发的证书。如果每个人最终都使用一个单独的CA（有些人担心使用Let's Encrypt可能会发生这种情况），那么我们将所有信任都集中在那里，而失去了这种分散的优势。
最后，付费CA可能还会提供其他好处，例如商业支持或一百万美元的SSL保修。我对这两个方面都不太相信，但是它们是“让我们加密”所不能提供的。
我的头很痛...我有一个问题，我想吗？
使用您认为合适的东西！对于DV证书，几乎没有什么可以真正区分各种CA。我在专业和私下都使用“让我们加密”，对此我感到满意。
实际上，我认为避免“加密”的原因只有四个：
- 如果您需要EV（或OV）证书。
- 如果您不能或不想自动执行证书更新，并且三个月的证书有效期对您来说太短了。
- 如果您不信任“让我们加密”（但也请务必考虑其他措施，例如DNS-CAA，然后您也应该在浏览器中将“让我们加密”列入黑名单）。
- 如果您认为出于某种原因，Let's Encrypt将被终止或从浏览器中删除。
如果这些都不对您适用，请随时为您的证书付款。