SSL自签名证书

Question

首先，我知道我对SSL的基本原理有很多误解。

但在此之前，我想提供有关我的目标的信息:有一个用C#编写的Windows应用程序，还有一个集成到这个asp.net应用程序中的asp.net WebApi。连接到API的客户机是用几种编程语言编写的。我们需要以某种方式增加SSL。这不是一个公共应用程序，客户端将使用我们给他们的客户端证书构建他们的客户端应用程序。

以下是我对SSL的了解，它们可能是错误的，也可能是正确的；

-自签署证书比购买证书更安全。因为像Charles这样的应用程序可能会使一些已知的证书不安全。

-For我前面提到的作为目标的场景，必须分别有三个证书；

• 根证书，
• 与根证书相关的服务器端证书，
• 与服务器证书相关的客户端证书。

-Every客户端可以具有相同的客户端证书。

-Visiual Studio命令提示符足以创建这些证书。

此外，我需要一个文档的来源来完成所有这些步骤。

Answer 1

我想你想要的是所谓的证书钉扎。

默认情况下，SSL证书的使用方式如下：

• 证书是由一些权威机构签发的。Client (浏览器、Windows、Android等操作系统)拥有其信任的权限列表。如果证书是有效的(未过期，为我们连接到的域颁发)，并且是由受信任的权威机构颁发的--一切都可以。
• 有大量不同的权威和客户不能信任他们的所有。相反，它信任某些选定的“根”权限。
• 这些“根”当局将颁发证书的能力委托给这些根当局自己信任的其他较小的当局。
• 这可能会继续下去，因此存在一个信任链:证书由权威A颁发，权威B信任证书，“根”授权机构信任证书，而客户端(操作系统)则信任证书。

这种模式有几个弱点，其中之一就是你的客户信任的“根”权威的列表。有人，如您的公司管理员，您的政府，或ISP供应商，可以安装或强制您安装自定义证书到您的信任“根”当局列表。然后，它可以通过拦截SSL流量来执行中间人攻击，并使用安装到受信任列表中的自定义证书对其进行重新加密。

这样，客户端就会认为一切都是安全的，而在现实中，您的通信被拦截，响应被记录和\或修改。

如果你不喜欢这个-你可以使用证书钉。想法很简单--您只需在软件中嵌入api端点的预期证书即可。

通过这样做，您不再需要信任任何权威机构或验证上面的信任链。您需要验证的是，SSL握手期间提供的证书与嵌入到软件中的证书完全相同。

由于这个原因，您并不需要某个权威机构颁发的证书，您可以使用自签名的证书。

因此，如果您遵循此路径，发出自签名证书并将其嵌入软件(当然没有私钥)到软件(发送到客户端)，并指示他们验证您在SSL握手期间提供的服务器证书正是该证书。

缺点当然是，如果您的证书被泄露或过期-您需要更新所有的软件。如果说软件是由你控制的，这不是什么大问题，但如果软件是由第三方控制的，这可能是个问题。