这样的消息由一方（例如服务器）发送给另一方（例如客户端），以表示它与该方发送的密码元素有问题。名义上，这发生在以下情况：

bad_record_mac

   This alert is returned if a record is received with an incorrect
   MAC.  This alert also MUST be returned if an alert is sent because
   a TLSCiphertext decrypted in an invalid way: either it wasn't an
   even multiple of the block length, or its padding values, when
   checked, weren't correct.  This message is always fatal and should
   never be observed in communication between proper implementations
   (except when messages were corrupted in the network).

在 SSL/TLS 握手中，任何一方发送的第一个加密Finished消息是在应用程序数据之前的握手消息。当加密货币出错时，这将显示在那个时候，并带有bad_record_mac警报。

必须注意的是，当非对称密钥交换失败时，例如，如果服务器尝试解密客户端发送的 RSA 加密的“预主密钥”但没有找到正确加密的 RSA 消息，那么大多数现代服务器实现将保留使用随机的预主密钥。这是对Bleichenbacher 攻击的防御，该攻击试图通过猜测解密是否在 RSA 阶段或以后失败来获取有关服务器私钥的额外信息。为了应对这些攻击，服务器将错误“延迟”到Finished消息出现，并且会尽力不解释确切的错误原因。因此，虽然bad_record_mac名义上是完整性检查层的问题，但此类错误往往会出现在任何 加密相关的问题。

一个可能的原因如下：客户端使用的服务器公钥与实际的服务器私钥不匹配。通常，客户端将从服务器证书中提取服务器公钥，服务器在握手期间将其发送给客户端。服务器还拥有一个私钥，该私钥在数学上与公钥相关联。如果服务器配置为使用错误的文件，那么您可以获得您观察到的症状。

我建议您使用网络监控工具（例如Wireshark）来观察握手消息：您应该看到Certificate来自服务器的消息，其中包含服务器证书链；对于该链的第一个证书，您可以提取客户端将使用的服务器公钥。在服务器上，尝试打印出服务器私钥详细信息（这是否容易，取决于所涉及的软件和实际密钥存储），看看它们是否匹配。

其他可能的原因涉及一些加密算法的错误实现（在客户端和/或服务器上）。查明这些错误可能很困难。

要获取更多调试详细信息，您还可以尝试使用openssl命令行工具连接到服务器：

openssl s_client -connect theservername:443 -msg -debug

还可以尝试使用一些选项来选择协议版本 ( -ssl2, -ssl3, -tls1...) 和支持的密码套件 ( -ciphers)。最终，您甚至可以使用插入的自定义调试代码重新编译您自己的OpenSSL版本（以打印出中间值等）。OpenSSL 是开源的，所以如果你有一些 C 编程知识，这在技术上是可行的。

掌握 SSL 协议的一些细节会有所帮助。将此答案视为起点。