我经常发现自己在处理内部网中的不良证书（或没有正确签名证书的临时服务器）。我还没有遇到过一种方法，可以让我在浏览器中保存单个网站的证书（包括其 CN），而无需信任它作为其他网站的认证机构。这在概念上可行吗，还是这超出了 PKI 系统的设计范围？
编辑以澄清：假设我正在某个本地服务器上工作。megaserver我通过以下方式访问它https://megaserver在浏览器中。它有一个自签名证书。为了暂时安全地访问此服务器，我将其证书添加到浏览器中的 CA 存储中。有人窃取了该证书，为https://www.google.com，用证书签名megaserver，然后以中间人的方式攻击我。我的浏览器接受 Google 证书，因为它是由我系统上受信任的 CA 证书签名的。这种假设情况可能吗？
答案1
是的。
来自 RFC 5280：
4.2.1.9. 基本约束
基本约束扩展标识证书的主体是否为 CA，以及包含此证书的有效认证路径的最大深度。
然后它继续说：
如果版本 3 证书中不存在基本约束扩展，或者存在扩展但未断言 cA 布尔值，则不得使用认证公钥来验证证书签名。
验证证书签名实际上意味着充当 CA。
因此，如果您的自签名证书没有将基本约束 CA 设置为 true，则它不能用于签署从属证书。
您确定所有这些自签名证书都已将此标志设置为 true 吗？如果是这样，您确实需要与生成证书的人谈谈，并向他们介绍一些免费的在线 PKI 培训资源。
窃取证书并不危险——毕竟证书是公开的。但是窃取相关的私钥则危险，并且会使您的证书变得毫无用处。这个保护私钥的长期问题（在 PKI 世界中）导致了硬件安全模块的开发，以防止私钥落入坏人之手。不过，我怀疑您是否愿意为您的内部网自签名证书花费那么多钱。
更好的方法是确保管理谁可以登录创建这些证书的设备。使用 OpenSSL、GnuTLS、Java 等的系统可以用密码保护私钥。Windows 会加密私钥，但一旦管理员登录到这台 Windows 机器，私钥就很容易被拿走了。
答案2
问：我将其证书添加到浏览器中的 CA 存储中。有人窃取了该证书，并为 https://www.google.com
您添加到证书存储区民众自建本地 CA 的密钥。CA 私钥的唯一所有者可以签署某人的证书（正如你所说的https://www.google.com)，因此从您的浏览器窃取 CA 公钥是没有意义的，因为它不是秘密并且不能用于签署他人的证书。
问：我的浏览器接受 Google 证书，因为它是由我系统上受信任的 CA 证书签名的。这种假设情况可能实现吗？
您信任您的浏览器，而浏览器又信任特定范围的 CA。如果您在浏览器中将本地 CA 添加为受证书存储信任的 CA，那么您将自动信任此本地 CA 签名的所有证书。
这样，管理您本地 CA 的 IT 部门可能会为 google.com 颁发并签署虚假证书，并且您的浏览器会信任它，但是……这里有两个您需要了解的技术细节。
当你直接连接到某个https域名时，Web 服务器会回复公共证书，其中包含签署此证书的信息，并且浏览器会在其证书存储中查找签署此 Web 服务器证书的 CA，因此你可能会认为，对于那些试图伪造 google.com 的人来说，这将是一项艰巨的工作，他们应该设置虚假的 google.com 副本作为自己的 Web 服务器，并覆盖指向假装是 google.com 的虚假网站的 DNS 记录
但实际上这可以相对容易地完成。虽然听起来不可能（或很难做到），但我应该告诉你，这并不难，这实际上是许多公司的一种常见做法，即通过使用https透明（或授权）http 代理来监视/拦截流量，以达到各种目的（过滤、监控和记录）。
如果您将本地 CA 添加到证书存储区，那么如果您的公司使用 http 代理，此代理可能会为任何https连接动态生成虚假证书并将其提供给您的浏览器，并且您的浏览器将信任（如我之前所述）此类虚假证书。代理端可能会解密此类连接，因为它拥有所有已颁发证书的私钥，用于过滤、监控、记录，如果连接绕过代理的过滤器，代理将以客户端身份询问目标真实站点，然后重新加密回复并返回原始目的地（或者，如果某些规则要求，它可能会决定播放虚假的超时连接）。
如果您不想成为https过滤的对象，我建议您设置一些虚拟机（例如 VirtualBox），使用您熟悉的操作系统，并在其中添加本地 CA，同时保持主机不受本地 CA 感染。
另一个解决方案是，您可以在浏览器中使用不同的配置文件（Firefox 在这方面表现不错），一个用于工作，将保存您的本地 CA 证书，另一个是私人配置文件，不包括本地 CA。这样，如果您的https流量通过代理进行过滤，您（实际上是浏览器）可能会快速发现事件。