自签名证书风险

自签名证书风险

我目前正在使用自签名证书进行内部开发目的,并想确保我了解任何真正的安全风险。

以下是我的设置方法。

根证书

  1. 创建了根 CA .pvk 和 .cert
  2. 在本地计算机上的“受信任的根证书颁发机构”下安装了 CA 根证书。
  3. 在我的开发托管服务器上的“受信任的根证书颁发机构”下安装了 CA 根证书。

我的站点证书

  1. 从根 .cert 和 .pvk 生成另一个证书
  2. 将新证书作为 .pfx 文件导入托管服务器
  3. 设置托管服务器以在 IIS 中为我​​的网站使用新证书

除了根证书的私钥之外,还有其他数据如果被人获取,会带来安全风险吗?

答案1

您的站点证书(+私钥)应像任何站点证书一样对待。如果有人掌握了私钥,他们就能冒充您的网站。对于由商业 CA 颁发的证书,您必须信任托管服务,这两者之间几乎没有区别。

由于您创建了自己的 CA,因此很少有人会默认信任该 CA,因此这里的风险得到了缓解。这种风险实际上仅限于那些选择信任您的 CA 的人。

CA 私钥也是一样,只要掌握了它的私钥,就可以颁发任何证书。

最大的问题在于,用户界面倾向于平等对待所有受信任的 CA(EV 证书除外),或者如果用户不注意,则以非常相似的方式对待。因此,如果攻击者 (a) 拥有您的 CA 的私钥并且 (b) 知道信任此 CA 证书的用户,他们就可以创建对他们想要的任何网站有效的证书。

您的风险评估应考虑谁将选择信任此内部 CA。商业 CA 往往对其私钥的保护有严格的政策(通常,在智能卡或类似物上进行不可提取的存储):这通常是大多数浏览器批准纳入的要求。

更具体地说是关于“其他信息”。在设计 CA 时,制定有关属性和主题 DN 结构方式的策略可能很重要。我知道有些 CA 明确表示绝不会在证书中明确披露用户的身份(证书通常是公开的,并且在握手过程中经常对窃听者可见),因此主题 DN 只是一个内部 ID,CA 知道(并且可能通过加密的反向通道或类似机制与服务和 CA 之间的实际名称绑定在一起)。

答案2

只要人们知道这是自签名证书,内部自签名证书就不会构成风险。它们对客户构成的最大风险。

例如,当您分发给客户端并建立初始连接时,您需要确保他们验证它是否有效,但除此之外,使用第三方提供商的唯一好处是您不必担心攻击者假装是您的服务器,但这意味着你一开始就会被黑客入侵,并且还会遇到很多其他问题。

因此,最大的安全风险是没有告知人们这是一个自签名证书并验证其位置。至少在我看来是这样。此外,它们不受 CA 管理,因此您无法发出证书撤销,并且如果出现问题,您实际上必须重新制作密钥——但对于内部系统,我真的不会担心这一点。

相关内容