什么时候可以在生产中使用自签名证书？答案

【问题标题】：When is it acceptable to use self-sign cert in production?什么时候可以在生产中使用自签名证书？
【发布时间】：2017-07-27 21:14:27
【问题描述】：

自签名证书始终被视为仅用于测试的证书。但据了解，如果出于正确的原因使用它进行生产是完全可以的。我正在尝试向我的客户提供一些关于使用什么的指南。例如：

身份验证：不能使用自签名，因为浏览器不会信任“自我”颁发者。因此，对于服务到服务或服务到客户端的身份验证，不能使用自签名。除非在验证之前有预指纹/CN 白名单流程。很多人都这样做，例如我上传管理证书公钥的 Azure，用于对其 API 进行身份验证。
签名：不可以，因为发行人不信任。除非在验证之前有预指纹白名单过程。除非在验证之前有预指纹/CN 白名单流程。
加密：完全可以使用自签名，因为不需要链信任。万一受到攻击，MIM 证书根本不会解密，没有其他影响。

我希望社区提供一些想法/建议/指南，以确保我的建议朝着正确的方向发展。

谢谢。

【问题讨论】：

但是你为什么要首先使用自签名证书呢？与受信任的 CA 签名证书相比，没有任何优势。
CA 签名需要花钱，我的客户生成了 20000 多个证书，因此他们节省了很多钱。这就是为什么。
Let's encrypt 证书是不可能的？
我认为这个问题更适合security.stackexchange.com
案例 (3) 不是“完全可以”。在发生攻击的情况下，如果 MITM 证书最终被信任，则对等方最终将被信任，并且 SSL 将终止于攻击者，而他可以看到明文。证书不执行或参与 SSL 加密或解密。这不是与“(1) 身份验证”分开的威胁模型。

标签： security ssl certificate

【解决方案1】：

身份验证：不能使用自签名，因为浏览器不会信任“自我”颁发者。

只要存在受信任的离线证书分发过程，就可以使用。不能通过 'trust-all' 代码使用。

签名：不可以，因为对发行人没有信任。

只要存在受信任的离线证书分发过程，就可以使用。

加密：完全可以使用自签名，因为不需要链信任。万一受到攻击，MIM 证书根本不会解密，没有其他影响。

只要存在受信任的离线证书分发过程，就可以使用。关于“MI[T]M 证书将根本不会解密”的部分毫无意义。证书不执行解密，并且设法提供自己证书而不是目标证书的 MITM 将拥有相应的私钥，否则攻击毫无意义。在没有信任的情况下，如果发送者使用不受信任的证书中的公钥加密任何东西，他不知道谁能解密它，所以他是不安全的。

【讨论】：

@EJB 对于原始加密构造没有 MiTM，例如 PKCS#7/CMS/(S/MIME) EnvelopedData 的实现，它使用它创建会话密钥（对称密钥）和用证书公钥加密它。并用会话密钥解密用私钥解密。所以，我可以为此使用自签名。正如我提到的 SSL，以防我需要 CA 签名，除非它被列入白名单。例如MS Azure，我上传了公钥，然后我使用该证书来验证所有 REST 调用。因为那个自签名也很好，因为 MiTM 指纹没有被列入白名单。
@Bhaskar 不。正如我两天前在上面的评论中所说，MITM 攻击通过提供他的证书而不是正确的证书来起作用。如果您对这种攻击采取了预防措施，您只能使用自签名证书，即为它组织某种信任，这是最简单的通过 CA 签名来完成的。仅仅获取他人的证书并不构成任何形式的 MITM 攻击。根据定义，MITM 假装是对等方。他不仅仅是一个窥探者。

【解决方案2】：

我可以找到几个真正不需要可信 CA 的真实示例

VPN：服务器和客户端的证书
SSL/TLS 客户端身份验证：需要相互身份验证时用于客户端身份验证的证书
专用网络中的 SSL/TLS：内部服务或服务器群
非对称加密：真正需要的只是密钥，而不是证书。
在封闭环境中签名和授权：就像组织的员工使用由 abprivate CA 颁发的加密令牌
服务之间的消息认证：SOAP 签名、JWT 或 SAML 消息。接收方部分在其信任库中明确包含服务器签名证书以验证签名者身份

【讨论】：

所有这些都归结为一种情况：可以通过一些离线过程使对等方信任自签名证书。
完全是@EJP，信任颁发者的私有证书颁发机构可以在任何场景中完美地替换已知的“受信任”CA，签名、身份验证或加密。我的清单是使用它们的真实案例