SSL自签名证书

Question

首先，我知道我对SSL基础有很多误解。

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

这是我对SSL的了解，可能是对还是错。

-自签名证书比购买的证书更安全。因为某些已知的证书可能会使诸如Charles之类的应用程序变得不安全。

-对于我上面作为目标提到的这种情况，必须分别有三个证书；

• 根证书，

• 与根证书有关的服务器端证书，

• 与服务器证书有关的客户端证书。

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

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

另外，我还需要文档来完成所有这些步骤。

Answer 1

自签名证书比购买的证书更安全。不，...自签名证书只是客户端无法自行验证的证书，因为没有可信任的第三方说：“此证书还可以”您必须以自己的方式将证书安全地交付给客户端，方法可能是让管理员手动安装证书或将其与您的应用捆绑在一起...如果您无法控制某些客户，那么带有自签名证书的东西会变得很难看...对于这种情况，必须分别有三个证书；根证书，与根证书有关的服务器端证书，与服务器证书有关的客户端证书。据我了解，您希望SSL / TLS的x509证书对服务器进行身份验证并避免MITM攻击，而不是由服务器识别客户端在这种情况下，您只需要一个证书，或者如果以后要基于自己的PKI，则可能需要两个证书...具有一个证书的情况：创建密钥对并使用该密钥对自签名x509证书... ...私钥保留在服务器中，公钥将包含在证书中，该证书随应用程序一起提供，还分发给其他开发人员以供其客户端对服务器进行身份验证...在SSL / TLS握手期间，需要在客户端应用程序中使用此证书来对服务器进行身份验证这基本上是证书固定darwback：根据客户群的大小，替换此证书将变得很困难带有2个证书的案例：与上述相同，但是自签名证书实际上是可以用来对其他证书进行签名的根证书，特别是在此用例中：服务器证书...然后，客户端可以使用自签名的根证书来验证是否已使用根证书来对服务器证书进行签名，这使得更换服务器证书变得更加容易。您可能需要稍后做，并且还设置证书吊销列表，以防您需要使证书无效...-每个客户端可以具有相同的客户端证书。客户端所需的全部是（如@john所指出的）自签名服务器证书（案例1）/自签名根证书（案例2）-Visiual Studio命令提示符足以创建这些证书。显然，这一限制已解除...

Answer 2

我认为您追求的是所谓的证书固定。默认情况下，以以下方式使用SSL证书：证书是由某些机构颁发的。客户端（浏览器，操作系统，如Windows，Android等）具有其信任的权限列表。如果证书有效（未过期，为我们要连接的域颁发证书等）并且由受信任的机构颁发-一切正常有许多不同的权限，客户不能完全信任它们。相反，它信任某些选定的“根”权限。这些“根”权限将颁发证书的能力委托给其他较小的权限，这些权限由这些根权限本身信任。这可能会继续下去，因此存在信任链：证书由颁发机构A颁发，证书由颁发机构B信任，而颁发机构B则由“根”颁发机构信任，而“根”颁发机构又由客户端（您的操作系统）信任。该模型有几个弱点，其中之一就是客户信任的“根”权限列表。像您的公司管理员，您的政府或ISP提供商一样，可以安装或强制您将自定义证书安装到受信任的“根”权限列表中。然后，它可以通过拦截您的SSL流量并使用已安装到受信任列表的自定义证书对其进行重新加密来执行中间人攻击。这样，客户将认为一切仍然安全，而实际上您的流量被拦截，响应被记录和/或修改。如果您不喜欢这样-您可以使用证书固定。想法很简单-您只需在软件中嵌入api端点的预期证书即可。这样，您就不再需要信任任何授权机构或验证上面的信任链。您需要验证的是SSL握手期间显示的证书与您嵌入到软件中的证书完全相同。因此，您实际上并不需要某些权威机构颁发的证书，而可以使用自签名证书。因此，如果您遵循此路径-颁发自签名证书并将其（当然没有私钥）嵌入软件（发送给客户端），并指示他们验证SSL握手期间显示的服务器证书正是此证书。缺点当然是，如果您的证书被盗用或过期，则需要更新所有软件。如果所说的软件由您控制不是很大的问题，但是如果软件由第三方控制则可能是一个问题。