客户端请求SHA384签名算法时，服务器发送SHA256证书为何未报错？

为什么连接没有被拒绝？ #

你混淆了TLS协议中三个不同场景下的哈希算法用途，它们完全独立、互不冲突：

• 证书的SHA256签名：这是CA签发证书时用的哈希算法，作用是证明证书的真实性和完整性。只要证书链能通过验证（你的输出里显示Verification: OK），不管它用SHA256还是其他哈希签名，都不影响TLS握手——证书签名算法是证书本身的属性，和握手阶段协商的算法无关。
• -sigalgs指定的rsa_pss_rsae_sha384：这个参数限制的是服务器在TLS握手过程中签名握手消息（比如ServerKeyExchange）必须使用的算法。从你的会话信息里Peer signing digest: SHA384、Peer signature type: RSA-PSS能看出，服务器确实遵守了要求，用指定算法完成了握手消息签名，所以客户端不会拒绝连接。
• 密码套件中的SHA384：密码套件ECDHE-RSA-AES256-GCM-SHA384里的SHA384，是用来对加密后的TLS通信记录做完整性校验（生成消息认证码MAC）的。只要客户端和服务器都支持这个套件，就可以协商使用，和证书签名、握手签名算法没有绑定关系。

这三个环节的哈希算法各司其职，只要每个环节都满足协议要求，连接就能正常建立，不会出现你预期的“密码套件不匹配”错误。

SHA384与SHA256是否可互用？ #

SHA384和SHA256同属SHA-2哈希家族，但输出长度不同（SHA256是256位，SHA384是384位），算法本身不能直接互用——比如不能用SHA256的计算结果替代SHA384的结果，反之亦然。

但在TLS协议的不同环节中，它们可以同时存在：就像你这次的连接，证书用SHA256签名、握手签名用SHA384、通信记录校验用SHA384，这种组合完全符合TLS规范，因为每个环节的哈希算法作用不同，协议允许独立选择。

内容的提问来源于stack exchange，提问作者ABHISHEK PATIL