在以下用例中，我对SSL证书流程的理解是否正确（CA /自签名）。 通常，当我们生成SSL证书时，它具有以下内容 ：
第一个Web浏览器通过其自己的公钥获取SSL证书。 CA提供者证书存在时的证书验证：
但是博客也谈到浏览器已经具有受信任的根证书，并且它可以进行验证。这是否意味着浏览器多次仅检查证书内容而不进行数字签名验证（Q2）？
现在，在进行自签名的情况下，Web服务器将使用其自己的私钥来登录证书（而不是CA私钥）。在第一次浏览器交互期间，它将与网络服务器公共密钥一起发送其证书。因此，在这种情况下，我们在证书签名期间使用了相同的公钥/私钥对，并共享了用于数据加密的对称密钥（Q3）？
现在，博客说我们可以在浏览器上手动导入证书。证书导入是否也会导入公钥以验证签名正确（Q4）？ 博客说，如果“受信任的根”证书中存在证书，则认为该证书有效。这是否意味着浏览器不执行签名验证（Q5）？
有人帮助我理解Q1至Q5。我有什么想念的吗？
答案 0 :(得分：0)
您的帖子很难追踪，但我会尽力的。
如果在浏览器中安装了CA的根证书，则根据颁发的证书颁发机构（CA）对证书进行验证。
对于自签名证书，您是CA。
如果创建证书并为CA导入证书，则使用它创建的证书将受到信任。如果您不导入CA的证书，则不会信任您的证书。
但是博客也谈到浏览器已经具有受信任的根证书，并且它可以进行验证。
您的浏览器信任的CA的初始根证书集由浏览器的发布者安装。例如，这意味着全新安装的Chrome浏览器将信任由Verisign颁发的银行的SSL证书，而不是您的自签名证书。
从您自己的CA安装根证书后，您的浏览器将像信任Verisign一样信任您的证书。
对于标题中的问题，浏览器必须验证签名。如果不是这样，它将被破坏，这将是一个巨大的安全漏洞。
答案 1 :(得分：0)
由CA私钥或“自签名”签名的数字签名将是Web服务器自己的私钥（希望这种理解正确吗？（Q1））
正确。服务器的证书将由CA证书（根CA或更常见的是中间CA）签名。如果是自签名证书，则服务器的证书和CA是同一证书。
- Web服务器提供的最新公共密钥用于启动对称秘密密钥加密。
这仅适用于RSA密钥交换。使用RSA Kx，可以由客户端创建主密码，并使用服务器的公钥进行加密并将其发送到服务器。然后，客户端和服务器都将从该主密码之前的密钥中获取所有对称密钥。
RSA密钥交换已不建议使用，并随TLS 1.3一起删除。相反，应使用Diffie Hellman密钥交换。使用DH Kx，服务器证书和内部的公钥仅用于对服务器进行身份验证，以防止中间人攻击，但不参与密钥交换。
但是博客也谈到浏览器已经具有受信任的根证书，并且它可以进行验证。这是否意味着浏览器多次只检查证书内容而不进行数字签名验证（Q2）？
服务器发送服务器（叶）证书和可能的中间证书，然后浏览器从叶证书创建信任链，该信任链通向本地根证书（信任锚）。如果无法创建此类信任链，则证书不可信。哪种CA证书用作信任锚取决于客户端：像Firefox这样的浏览器带有自己的信任库，其他浏览器使用系统信任库，其他客户端使用另一个信任库（即Java带有自己的信任库）。有关更多详细信息，请参见SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?。
现在是自签名的，.....因此，在这种情况下，我们在证书签名期间使用了相同的公钥/私钥对，并共享了用于数据加密的对称密钥（Q3）？ / p>
对于自签名证书，颁发者和证书的本身就是证书，即用于签名证书的私钥与证书内的公钥匹配。如果使用RSA密钥交换，则此密钥还涉及创建对称密钥（请参见上文）。
证书导入是否也会导入公钥以验证签名正确（Q4）？
公钥是证书的一部分（但不是私钥）。因此，证书导入也将隐式导入公钥。
博客说，如果“受信任的根”证书中存在证书，则认为该证书有效。这是否意味着浏览器不执行签名验证（Q5）？
根证书被认为是受信任的，因为它在本地信任存储中，而不是因为它是由某些人签名的。这就是为什么签名验证与根证书并不真正相关的原因。为了正确地用作信任锚，SSL / TLS库仍然经常需要根证书是正确的（自签名）证书。