以 Verisign 的网站为例，该网站的根 CA 具有 sha1 哈希签名。我是否理解错了，如果发现冲突，他们可以冒充 Verisign 根 CA，并使用它来生成中间证书，然后生成受浏览器或操作系统信任的服务器证书。
https://www.entrust.com/need-sha-2-signed-root-certificates/ 状态：
简而言之，由于软件直接信任根证书公钥，因此根证书上的签名无需验证。根证书是自签名的，不是由其他被授权的实体签名的。根证书通过操作系统或浏览器开发商管理的根证书程序获得授权。
并引用了 Google 链接： https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
注意：基于 SHA-1 的受信任根证书签名不是问题，因为 TLS 客户端通过其身份而不是哈希签名来信任它们
假设我是一款新型浏览器 SuperUserBrowser 的作者。除了哈希签名之外，我还能用什么其他方式来确保我随浏览器提供的根证书是真实的呢？
为什么具有 SHA1 签名的根 CA“没有问题”？
答案1
我是否误解了，如果有人发现冲突，他们就可以冒充 Verisign 根 CA，并使用它来生成中间证书，然后生成浏览器或操作系统信任的服务器证书。
您错了。
至于签名本身的安全性：
证书的签名用于验证该证书的颁发者，以建立信任链。由于根 CA 是信任链的受信任端（因为它是预先信任的，即存储在操作系统的信任存储中），因此根 CA 的颁发者不需要验证，因此根 CA 的签名无关紧要。
对于使用弱哈希算法签名的根 CA 创建新证书：
要签署另一个证书（即创建叶证书或中间证书），您需要拥有 CA 的私钥。与证书公钥匹配的私钥不能从证书颁发者颁发的签名中得出，即使证书是自签名的（即使用尝试获取的私钥签名）。
签署证书的方法是先使用不可逆哈希算法对证书的基本部分进行哈希处理，然后使用颁发者的私钥对其进行“加密”。要获得签署新证书所需的私钥，您需要攻击加密（RSA 或 ECC），即找到一个密钥，该密钥在“加密”哈希证书时会产生相同的签名。但是，由于 RSA/ECC 签名尚未被破解，因此您无法提取私钥，因此无法使用此密钥生成新证书。另一种使用此证书签署新证书的方法是创建一个产生相同哈希值的证书。但是，虽然 SHA-1 容易受到碰撞攻击（即找到具有相同输出的两个输入），但它（与 MD5 相反）目前不易受到您需要的原像攻击（找到给定输出的输入）。这意味着这种攻击媒介也失败了。
答案2
我是否误解了，如果有人发现冲突，他们就可以冒充 Verisign 根 CA，并使用它来生成中间证书，然后生成浏览器或操作系统信任的服务器证书。
您误以为仅通过哈希碰撞就能冒充根 CA，因为成功攻击根 CA 的证书需要更多步骤，如下所详细解释的那样。
但是，正如下面所述，您可以仅使用哈希碰撞就成功模拟中间 CA。
简而言之，客户端验证证书上的 RSA 加密签名是否与使用 CA 的公钥对 TBS 证书字节的哈希值进行签名而生成的 RSA 加密签名相匹配。虽然 CA 的公钥可用于验证 TBS 证书哈希值的 RSA 加密签名，但需要知道 CA 的私钥才能生成允许您冒充 CA 的签名。
假设您能够通过修改 CA 根证书以包含您知道其私钥的公钥来生成 TBS 部分的哈希冲突，那么问题在于您修改后的 CA 证书将包含与 CA 的实际证书不同的公钥，并且任何验证由 CA 签名的证书的客户端都将拥有 CA 真实证书的本地安装副本。在验证签名证书时，客户端将从签名证书中检索签名者的指纹或签名，并在尝试验证由该 CA 签名的证书的签名时检索该证书的本地副本的公钥。
因此，为了冒充根 CA 并生成客户端信任的 RSA 加密签名，您首先需要从您生成的包含您知道私钥的公钥的 TBS 证书中找到根 CA 证书的 TBS 部分的碰撞。您还需要找到这样的碰撞，该碰撞通过使用 CA 的公钥通过 RSA 签名验证。此时，您将获得一个伪造的证书，该证书既有 SHA1 哈希碰撞，又有 RSA 签名碰撞。如果您以某种方式完成了所有这些，您最终将需要欺骗客户端，以便他们在查找根 CA 证书时检索您的伪造证书，而不是检索根 CA 证书的本地副本。
在几乎所有可以想象的场景中，您可以完成所有这些事情，从而拥有更有效的攻击机会，而不需要首先找到包含您已知私钥的证书的 SHA1 哈希碰撞，这也会生成 RSA 加密签名碰撞，然后需要诱骗客户端使用签名验证，而不是使用真正的根 CA 证书，鉴于客户端信任它，该证书将本地存储在客户端上。
相反，更合理的攻击是找到中间 CA 证书的哈希碰撞，然后您可以使用该证书冒充中间 CA 来签署证书。这种攻击更合理，原因有二：首先，您可以轻松让客户端下载中间 CA 的证书；其次，哈希碰撞将根据受信任 CA 的 RSA 加密签名进行验证，因此无需尝试诱骗客户端信任签署证书的 CA。
如果客户端收到来自某个网站的证书，而该网站由中间 CA 签名，但客户端没有该证书的本地副本，客户端将尝试从最初提供证书的网站下载中间 CA 的证书。回想一下，客户端将获取此中间 CA 证书的 TBS 部分的哈希值，然后验证此证书上的 RSA 加密签名确实是使用本地受信任 CA 的公钥或指向本地受信任 CA 的 CA 链的公钥签名的，成功的攻击现在简化为生成有效中间 CA 证书的 TBS 部分的哈希碰撞。
一旦可以将可验证中间 CA 证书的公钥替换为私钥已知的公钥，然后根据需要修改其他字节以生成与可验证证书的哈希冲突。然后可以使用此更改后的证书签署其他证书。然后，可以将这些签名的证书与修改后的中间证书一起安装在 Web 服务器上。当客户端检索证书时，它将读取签署该证书的 CA 的指纹。如果客户端未在本地安装此中间证书，它将从其检索正在验证的证书的网站下载证书。然后，客户端将生成 TBS 网站证书的哈希，并使用其下载的中间 CA 证书中的公钥验证它是否经过数字签名。此过程是递归的，因为它随后创建其下载的中间证书的 TBS 部分的哈希，并读取签署中间证书的 CA 的指纹。然后，它将查找该 CA 的证书，并验证中间证书上的 RSA 加密签名是否是使用颁发 CA 的公钥对中间证书中的 TBS 证书的哈希进行签名而生成的。由于中间证书中的 TBS 证书的中间哈希与原始中间证书的哈希匹配，并且签名也与原始中间签名的签名匹配，因此我们修改后的中间 CA 的证书将得到验证。客户端将递归完成该过程，直到找到由其信任的 CA 颁发的证书，并且验证成功，我们已成功冒充中间 CA。
NIST 和 NSA 警告称
“2016 年 1 月之后，SHA-1 不应再被信任，因为资金雄厚的攻击者或政府越来越有可能找到 SHA-1 哈希碰撞，从而冒充任何 SSL 网站”，微软和谷歌在一年后开始对使用 SHA-1 的连接发出警告。
http://windowsitpro.com/security/你的组织-using-sha-1-ssl-certificates
证书链必须使用 SHA-2 证书加密。（证书链由认证最终证书所需的所有证书组成。）这意味着在 2017 年 1 月 1 日之后，任何中间证书也必须使用 SHA-2。通常，您的 CA 在提供 SHA-2 证书时会提供中间 CA 证书和根 CA 证书。有时他们会提供下载证书链的链接。使用 SHA-2 证书更新此链非常重要。否则，Windows 可能不会信任您的新 SHA-2 证书。
根证书则不同。这些证书实际上可以是 SHA-1 证书，因为 Windows 隐式信任这些证书，因为操作系统直接信任根证书公钥。根证书是自签名的，不是由其他被授权的实体签名的。
出于同样的原因，任何自签名证书都可以使用 SHA-1 算法。例如，Microsoft Exchange Server 在安装期间生成自签名 SHA-1 证书。这些证书不受新 SHA-2 策略的约束，因为它们未链接到 CA。不过，我预计 Exchange 的未来版本将在自签名证书中使用 SHA-2。