可以使用WCF的自签名证书安全吗？

想象一下，我们使用WCF（私钥/公钥对）使用经典的不对称签名。显然这是安全的，直到私钥不被盗。我们不需要钥匙之间的任何信任链，对吧？客户端只需要知道其服务器的公钥，反之亦然。可以使用WCF的自签名证书安全吗？

只有当客户端事先不知道服务器的公钥并在第一次访问时获得它时，才会出现问题。这里我们有一个风险，即实际的服务器是一个“中间人”而不是真正的服务器。我们需要证书。客户端访问服务器，获取其证书（其中包含公钥），并且验证它。

验证客户端需要确保服务器的证书是针对此特定服务器颁发的。在这里，我们需要信任链。对？

如果客户端通过WCF使用MessageSecurity.Mode = Certificate预先知道服务器的证书（它的公钥），那么即使证书是自签名的，我们可以说通信是安全的吗？

Usualy认为使用自签名certifacate不安全，应始终避免在生产中使用。
但是为什么？如果客户端知道预期的公钥，然后获得证书，将其视为可信（通过将其公钥与预期的公钥相匹配），那么它不会取消服务器必须使用其私钥加密有效载荷这一事实。当且仅当私钥和公钥一起创建时，密钥才能用pulbic密钥成功解密。

你能在我的推理中看到任何缺陷吗？

如果它是正确的，那么我可以确定使用自定义X509CertifacateValidator并将客户端代理的ClientCredentials.ServiceCertificate.DefaultCertificate设置为某些固定（在客户端上）X509Certificate安全吗？

定制X509CertifacateValidator是这样的：

public class CustomCertificateValidator : X509CertificateValidator 
{ 
    private readonly X509Certificate2 m_expectedCertificate; 

    public CustomCertificateValidatorBase(X509Certificate2 expectedCertificate) 
    { 
     m_expectedCertificate = expectedCertificate; 
    } 

    public override void Validate(X509Certificate2 certificate) 
    { 
     ArgumentValidator.EnsureArgumentNotNull(certificate, "certificate"); 

     if (certificate.Thumbprint != m_expectedCertificate.Thumbprint) 
      throw new SecurityTokenValidationException("Certificated was not issued by trusted issuer"); 
    } 
}

来源

2010-12-01 Shrike

我认为这与信任有关，而不是安全。证书颁发机构（CA）颁发的证书是可信的，例如，如果FF或IE浏览器将显示绿色栏，如果他们信任签名证书的CA。（Geotrust或Verisign）生成您自己的证书并保证您的私钥安全，应该没问题，但是256位VeriSign证书可以比自己生成的256位证书更安全吗？ CA可以做的一件有用的事是撤消证书。在这种情况下，客户端可以检查CA，以确保证书仍然有效。 – 2010-12-01 17:58:36

是的，你的理解是正确的，但是它忽略了一两件事 - 东西随着时间的推移而改变。如果服务器的私钥被泄露或者服务器的证书以其他方式（无论何种方式）变得无效，PKI提供证书撤销和撤销检查的机制。并且使用自签名证书这是不可能的（至少不建立定制的PKI基础设施）。

解决此问题的一种方法是创建将用作CA证书的自定义自签名证书。使用此证书签署服务器证书并将吊销信息放入CA证书。然后在客户端添加CA证书作为可信，并对该CA证书执行服务器证书验证并检查撤销。这意味着您必须在某些（可能是私有的）Web服务器上发布CRL，或者运行OCSP响应程序。

来源

2010-12-01 17:59:37

+1 - 我在想同样的事情，但并非100％确定。另外我认为一些生成证书的算法比其他算法更好？同样增加密钥大小可能会使某些证书更加安全。我的意思是，花更长的时间来猜测关键。 – 2010-12-01 18:04:22

可以使用WCF的自签名证书安全吗？

回答

相关问题