我们有一个 Web 应用程序，我们在他们的展会展位上为客户运行。直到最近，客户端和服务器之间的通信都是通过 HTTP 完成的。
我们目前正在努力改进此应用程序的几个与安全相关的方面。例如，我现在实现了对 HTTPS 的支持，并编写了一个小脚本来为服务器生成一个自签名证书。客户端应该将此证书添加到其受信任的证书存储中，以便浏览器不会抱怨它。到现在为止还挺好。
在聊天中，有人提到我不应该使用独立的自签名证书，而应该使用证书颁发机构来签署我的证书，即使 CA 本身是自签名的。
鉴于我仍然必须手动信任客户端上的自签名 CA，从安全的角度来看，我看不出这有什么好处。我想在某些情况下会稍微方便一些，但我们通常会在每次部署后删除客户端和服务器，并在下次需要设置系统时重新映像。
区别取决于有关自签名证书的一些细节以及浏览器和操作系统将如何对其作出反应。
普通证书包括一个Basic Constraints扩展，其中包含一个标志，表明证书是否适用于 CA；当标志为时，TRUE则该证书被认为可以作为其他证书的颁发者。如果扩展完全丢失，则证书将被视为非 CA。
根 CA 证书是“特殊的”；它们不是真正的证书。他们是信任锚；TA 名义上是与名称相结合的公钥。将信任锚编码为证书是传统的做法，由于证书包含签名字段，因此必须在其中存储一些字节；再一次，Tradition 说我们应该让证书自签名。但是，没有人真正检查该签名。大小合适的垃圾字节也可以。
棘手的一点是，在这样的“根 CA 证书”中发现的证书扩展（如果有的话）的解释是非标准的。特别是，一些历史根 CA 可以追溯到Basic Constraints扩展发明之前；作为真正的证书，它们将被解释为“非 CA”，但由于它们是伪装成证书的信任锚，因此不适用正常的解释规则。
因此，在某些浏览器或操作系统上，非 CA 证书（缺少Basic Constraints扩展名，甚至具有cA标志设置为的证书FALSE）一旦安装在“根 CA”存储中，很可能会开始被接受为 CA。因此，安装在用户信任库中的任何证书的私钥的机密性是相当关键的。
你的情况有什么不同？毕竟，在你的情况下，有两种选择：
在这两种情况下，用户都将他的安全性交给您的某些证书，用户将其安装为“受信任”。那么它会改变什么呢？
不同的是，如果使用自定义 CA，可以很好地保存对应的私钥。例如，您在始终处于离线状态的笔记本电脑上进行 CA 业务。当根本没有网络时，就不可能进行远程攻击。根 CA 应始终处于脱机状态，并且仅用作手动过程的一部分和用于数据传输的 USB 密钥。另一方面，您的服务器是一台服务器，因此它是在线的并且本质上是公开的。入侵您服务器的攻击者可能会获得服务器私钥的副本。如果相应的公钥已作为“受信任的根”安装在用户的机器中，那么攻击者也会在这些机器上获得很多利用。
简而言之，将自定义 CA 与服务器的证书（整天都在使用）区分开来，可以更好地保护私钥，从而降低灾难性攻击者权力升级的风险。
有些浏览器没有那么脆弱。对于自签名服务器证书，您真正想要的是用户仅信任该证书用于 SSL 连接（而不是作为 CA），并且仅用于该特定服务器。Firefox 知道如何做到这一点。它在 Firefox 术语中称为“安全例外”（请参阅首选项 -> 高级 -> 证书 -> 查看证书，然后是“服务器”选项卡）。