首先，我知道我对SSL的基本原理有很多误解。
但之前，我想提供有关我的目标的信息;有一个用C＃编写的Windows窗体应用程序，并且有一个集成到这个Windows应用程序的asp.net WebApi。连接到API的客户端使用多种编程语言编写。我们需要以某种方式添加SSL。这不是公共应用程序，客户端将使用我们将提供的客户端证书构建其客户端应用程序。
以下是我对SSL的了解，可能是错误的或正确的;
- 自签名证书比购买证书更安全。因为一些已知的证书可能会被像Charles这样的应用程序变得不安全。
- 对于我上面提到的作为目标的场景，必须分别有三个证书;
- 每个客户端都可以拥有相同的客户端证书。
-Visiual Studio命令提示符足以创建这些证书。
此外，我需要一个文档来源来完成所有这些步骤。
答案 0 :(得分：3)
自签名证书比购买证书更安全。
nope ...自签名证书只是客户无法自行验证的证书，因为没有可信任的第三方说：“此证书可以”
您必须以自己的方式安全地将证书交付给客户，可能是让管理员手动安装或将其与您的应用捆绑在一起......
如果您无法控制某些客户，那么使用自签名证书会让事情变得丑陋......
对于这种情况，必须分别有三个证书;
root cert，
与根证书相关的服务器端证书，
与服务器证书相关的客户端证书。
据我所知，您希望SSL / TLS的x509证书对服务器进行身份验证并避免MITM攻击，而不是服务器识别客户端
在这种情况下，你只需要一个证书，如果你想在以后建立自己的PKI，可能需要两个......
一个证书的情况：
创建密钥对并自行设置x509证书...私钥与您的服务器保持一致，公钥将包含在证书中，该证书随您的应用程序一起提供，并且还分发给其他开发人员以供其客户使用验证服务器......
在SSL / TLS握手期间，客户端应用程序需要使用此证书对服务器进行身份验证
这基本上是证书固定
darwback：取决于客户端库的大小，它将成为替换此证书的挑战
2个证书的案例：
与上述相同，但自签名证书实际上是一个可用于签署其他证书的根证书，特别是在这个用例中：服务器证书...
客户端可以使用自签名根证书来验证根证书是否用于签署服务器证书，这使得更换服务器证书更容易...
您可能希望稍后执行此操作并设置证书吊销列表，以防您需要使证书无效...
- 每个客户端都可以拥有相同的客户端证书。
所有客户端需求（如@john已指出）自签名服务器证书（案例1）/自签名根证书（案例2）
-Visiual Studio命令提示符足以创建这些证书。
请注意，makecert的文档声明“证书创建工具仅生成X.509证书，仅用于测试目的。”
显然这个限制被解除了......
答案 1 :(得分：2)
我认为你所追求的是证书钉扎。
默认情况下，SSL证书以下列方式使用：
证书由某些机构颁发。客户端（浏览器，操作系统，如Windows，Android等）具有其信任的权限列表。如果证书有效（未过期，为我们连接的域发布等）并由受信任的机构颁发 - 一切都很好
有很多不同的权威，客户不能信任所有人。相反，它信任某些选定的“根”权限。
这些“根”权限委托向其他较小的权威机构颁发证书的能力，这些权威机构自己信任这些权力机构。
这可能会继续，因此存在信任链：证书由权限A发布，权限B受权限B信任，受“root”权限信任，而“root”权限又受客户端信任（你的操作系统。）
该模型有几个弱点，其中一个是客户信任的“根”权限列表。有人，例如您的公司管理员，或您的政府或ISP提供商，可以安装或强制您将自定义证书安装到您信任的“根”权限列表中。然后，它可以通过拦截您的SSL流量并使用安装到受信任列表的此自定义证书重新加密来执行中间人攻击。
这样客户就会认为所有内容仍然是安全的，而实际上您的流量被拦截并且响应被记录和/或修改。
如果你不喜欢这个 - 你可以使用证书固定。想法很简单 - 您只需在软件中为您的api端点嵌入预期的证书。
通过这样做，您不再需要信任任何权威机构或验证上述信任链。您需要验证的是，SSL握手期间提供的证书与嵌入软件中的证书完全相同。
出于这个原因 - 您实际上并不需要某些机构颁发的证书，您可以使用自签名证书。
因此，如果您遵循此路径 - 发出自签名证书并将其嵌入（当然没有私钥）软件（发送给客户端）并指示他们验证在SSL握手期间提供的服务器证书正是此证书。< / p>
缺点当然是如果您的证书被泄露或过期 - 您需要更新所有软件。如果所述软件由您控制，这不是一个大问题，但如果软件由第三方控制，则可能是一个问题。