SSL / TLS数字签名交换

Question

如果服务器正在发送其数字签名，则在其中向客户端提供数字签名。

是在server_hello消息之后，因为在那里交换证书的公钥，这是解密数字签名所需的，还是带有包含公钥的初始证书。

如果密码套件是在change_cipher_spec协议后相互确认的，那么使用哪种哈希算法对数字签名进行哈希处理？

Answer 1

没有单独的“数字签名交换”。证书是一个自成一体的东西；它包含一个“颁发者”字段(带有签名的CA DN )和一个“签名”字段(带有来自该CA的签名)。服务器不只是在ServerCertificate消息中发送证书；它发送整个证书链，首先是他们的证书，然后是他们的CA，然后是CA的CA，然后继续到信任根(服务器希望客户机信任它)。

对于DHE和ECDHE (它们有用于密码参数交换的签名)，这些参数上的签名是包含参数的ServerKeyExchange消息的一部分。同样，没有单独的签名交换。

至于使用哪种哈希算法:这实际上与密码套件并没有本质上的关系，因为证书签名是X.509。签名算法也包含在强制证书字段中。X.509证书包含验证它所需的所有信息，但颁发者的公钥除外。某些密码套件不允许使用正确的算法签名的证书，但这会在稍后出现--您仍然可以在获得证书链后立即验证签名。

响应您的评论:签名验证证书，而不是服务器。服务器被隐式验证，因为其他操作证明它们拥有与该证书中的公钥相对应的私钥。作为一个单独的问题，在任何时候都不能用私钥加密；这是一个流行且错误的签名概念。签名算法接收消息(不是散列)并输出签名；任何散列都是签名算法的一部分。

编辑2:让我尝试解释一下证书验证过程。下面是一个示例证书链的图片；蓝色箭头“是相同的”(例如，Issuer DN是CA的主题DN )，绿色箭头的意思是“生成”(即通过签名，这不是加密，您不应该称之为加密)：

服务器在服务器证书消息中显示所有四个证书。然后，客户端使用以下一般证书验证过程验证服务器证书：

1. 如果证书与预先设置的“受信任证书”列表中的内容相同(例如可信根CA证书，或者如果您手动添加了受信任的根证书)，则接受证书。如果不是，这是链中的最后一个证书，请拒绝它(您不信任验证它的人)。
2. 如果没有，请检查证书是否过期，以及证书开始生效的日期是否在将来(这些属性我没有显示)。
3. 检查颁发者、签名算法和证书上的签名。如果您收到的证书列表中有下一个证书，请验证该证书的主题DN是这个证书的颁发者DN。
4. 使用来自下一个证书的公钥和来自此证书的签名算法，验证该证书上的签名。
5. 验证下一个证书是否具有CA属性。
6. 使用相同的进程在行下验证下一个证书。

如果任何步骤2-6失败，请拒绝证书。这都是使用服务器证书消息中的信息完成的，该消息包含完整的证书链(好的，所以从技术上讲，您可以省略自签名的根CA，TLS客户端将检查其信任根以获得具有适当主题DN的证书，但这是次要的细节)。最后，您知道服务器证书是一个证书链的开始，每个证书都由下一个证书签名，最后一个证书是您天生信任的证书(它是根CA)。没有单独的签名交换；这些签名是证书的一部分。