本文主要讲述互联网用户和网站所有者可以如何修复SSL/TLS握手失败错误。
与许多SSL错误消息一样，SSL/TLS握手失败可以从客户端和服务器端触发，因此，有时，普通互联网用户就可以修复它，但其他时候，有证据表明，是网站的配置出现了问题。
然而，不用担心，接下来我们将深入了解什么是SSL/TLS握手，SSL/TLS握手失败的原因以及修复它的具体方式。
让我们来看看吧。
什么是SSL/TLS握手？
在每个HTTPS连接开始时，客户端（互联网用户的web浏览器）和服务器（托管网站）都必须通过一系列检查来相互进行验证，并确定加密连接的参数。
TLS握手主要完成三件事：
如果你想要简化PKI——作为整个SSL/TLS生态系统的基础设施——实际上你是在处理有关安全密钥交换的问题。在HTTPS连接期间，通信实际上是使用在客户端生成的对称会话密钥（通常是256位AES密钥）来完成的。对称密钥生成后，双方都会得到一个副本，然后就可以使用它进行加密和解密。
虽然256位加密仍然足够强大，但真正起到保护作用的是一个长度更长、安全性更高的私钥（通常是2048位RSA密钥），因为它帮助处理了连接的身份验证问题。身份验证很重要，因为客户端希望确保连接的另一方是正确的。从本质上来说，这就是握手的目的。它会在对两端的客户端和服务器进行身份验证时进行一系列检查,确定出HTTPS连接的参数（将会使用的密码套件）,然后客户端会对会话密钥的副本进行加密，并将它发送到服务器，以供连接时使用。
一直以来握手都会使连接有所延迟，这导致一部分人称，HTTPS会减缓网站的运行速度。但是，最近几个版本的TLS协议已经解决了这一延迟的问题，因此该问题几乎已经不存在了——特别是在HTTP/2和HTTP/3中。
目前，有两个不同版本的TLS握手。TLS1.2使用的握手会在客户端和服务器之间进行多次往返。
我们并不打算逐步阐述，但从本质上来说，这一过程包括客户端和服务器彼此进行连接,然后SSL/TLS证书出现，客户端对其进行身份验证，彼此交换受支持的密码套件列表并就其中一个达成一致，最后交换密钥。
1.3将TLS握手简化为了单次往返。
SSL/TLS握手失败错误概述
现在让我们来深入研究一下如何解决这些问题，我们可以做什么，然后我们讲述将一些你绝对不应当在客户端进行的事情，不管是否是为了修复这一错误。
SSL/TLS握手失败——客户端错误
每次握手失败时，通常都是网站/服务器及其SSL/TLS配置出现了问题。
实际上，此时只是TLS配置不再支持SSL3.0。
但是，正如我们所讨论的，TLS握手中不确定的因素很多，有时甚至是最微小的问题都有可能导致整个过程失败。
因此，让我们来看一下几种客户端修复办法。
浏览器错误
这并不是一个浏览器错误，这实际上是你的浏览器犯了一个错误。有时你的浏览器可能会配置错误，或者插件可能导致工作方式稍有不同，从而导致连接到其他合法网站出现了问题。虽然准确地诊断出当前浏览器上需要更改的内容可能有点困难，但解决办法相当简单：只需要尝试使用另一种浏览器。
如果你使用的是谷歌Chrome浏览器，则切换到你的操作系统的原生浏览器，比如苹果的Safari或微软的Edge，或者如果你有的话，切换到MozillaFirefox。
只要打开它，然后试着连接到网站。如果SSL/TLS握手仍旧失败，那么你就知道这不是浏览器的问题。但是如果你能连接，现在你就知道你的插件或设置出了问题。
中间人（Man-in-the-Middle,MITM）
人们通常将MITM描述为试图窃取信息或造成伤害的邪恶黑客，但事实上并不是这样的。为了检查或负载平衡等其他目的，许多程序和设备都会拦截流量，然后将其发送到应用服务器。这也构成了一个MITM。
不幸的是，这些设备上的问题有时会导致TLS握手失败。它可以是阻止连接的网络防火墙，也可以是服务器端网络上边缘设备的配置——因此这个问题实际上可能还是客户端的问题——或者根据情况的不同，是服务器端修复的问题。
事情是这样的，如果这个问题存在于客户端，那么你可以更改防病毒或VPN的设置，但这会将自身暴露在外。通常，应该可以建立一份白名单，将存在疑问的网站排除在外，但千万不要关闭防火墙或防病毒软件，只是单纯地连接到网站。如果问题存在于服务器端，则可能是边缘设备上的配置出现了问题。最近，RossThomas就告诉我，他处理过这样一个设备，为了表明它通过了检查，这个设备试图拦截流量，然后再附加上一个小数据串。这导致数据校验和散列失败，还可能会干扰身份验证。
再一次地，有太多可能的原因，因此很难用一种方法概括，但是，如果你有设备正在试图检查或拦截流量，那么这可以作为参考。
SSL/TLS握手失败：服务器端错误
协议不匹配
该错误实际上在客户端和服务器端都有可能发生，而且根据情形的不同，事实上可能并不值得修复。当涉及到支持协议和密码时，最重要的一点是：永远向前看，决不回头。
TLS1.2在十年前问世，但仍然有一小部分网站不支持它。今年夏天早些时候，IETF最终将TLS1.3发布为RFC8446。我们建议如果可以，各个网站应当尽早添加对TLS1.3的支持。
另一方面，PCIDSS最近要求，所有收集支付卡信息的网站都必须结束对SSL3.0和TLS1.0的支持。此外，四大浏览器制造商——谷歌、Firefox、苹果和微软——共同宣布，将在2020年弃用TLS1.1。
如果由于协议不匹配而导致SSL/TLS握手失败，这意味着客户端和服务器不能相互支持相同的TLS版本。这里有一个例子：
在这个场景中，并没有相互支持的TLS协议，而且服务器可能不支持向后版本控制。服务器不应该修复这个问题。在这个例子中，客户端应该升级其浏览器，或者维持浏览器不变，但需对它进行配置以支持最新的TLS版本。
此时，你应该在使用TLS1.2或TLS1.3，如果不是，请添加对它们的支持。但是记住，永远不要走回头路。
密码套件不匹配
这与协议不匹配非常相似——只是更精细一点。SSL/TLS并不能处理所有的事情（尽管ECC已经很接近了），它实际上是一组服务于不同功能的算法，这些算法协同工作共同组成了SSL/TLS。
SSL/TLS就像Megazord一样，而密码套件就像PowerRangers一样。
什么？你试图使一组算法听起来更有趣。
无论如何，尽管TLS1.3所使用的密码套件已经得到了改进，但传统密码套件的算法可以处理：
不同的行业和政府机构拥有不同的加密标准，而这些加密标准又会建议使用不同的密码套件。一般来说，很有多重叠的地方，而且大多数网站都支持少量密码套件，因此客户端就拥有多个选择，并且通常都能找到一个双方都同意的密码。显然，如果网站只支持一个密码套件，那么协商成功的可能性就会大大降低。
如果你正在执行SSL桥接（边缘设备接收并解密HTTPS通信流，然后重新加密它，以便将其发送到应用程序服务器），那么在网络中通常都会发生这种情况。如果边缘设备和应用程序服务器不共享一个相互支持的密码套件，那么就会导致错误。
就像协议版本一样，在使用密码套件方面，你应该只向前看—而不是向后看。请记住，当一个协议版本或密码套件被弃用时，并不是因为行业试图让事情变得很困难，而是因为已经发现或即将发现漏洞。因此，向后看可能只会让你的连接不那么安全。
不正确的SSL/TLS证书
有许多因素可以使浏览器将SSL/TLS证书看作是不正确的，并阻止握手过程成功进行。我们将在下一小节中逐一介绍。同样值得注意的是，与SSL/TLS握手失败消息不同的是，有时这些问题会在客户端物化为一个不同的错误。一般来说，致使网站不能安全地进行连接的原因有多种。但从技术层面上来说，这个错误是握手失败造成的。
不正确的主机名
WWW和非WWW网站过去会出现这个问题，但是，由于证书机构允许免费将证书作为SAN列出，该问题已经普遍得到了解决。这个问题通常可以通过重新颁发证书来解决，有时也可以通过使用通配符证书来解决。
错误的证书链
几个月前，我们深入探讨了证书链、根和中间证书，但是可归纳如下。SSL/TLS和PKI中的信任模型通常依赖于精心策划的根程序，而这些根程序是一系列可信的、真实存在于计算机系统中的CA根证书的集合。
这些CA根如此宝贵，以至于证书颁发机构并不会冒险直接从这些根签发证书，而是会创建中间根，并使用这些中间根来签发SSL/TLS终端实体证书。这儿就要提到链了。根CA证书用于对中间根进行数字签名，而这些中间体则用于对其他中间体或SSL/TLS终端实体证书进行签名。
当浏览器接收到SSL/TLS证书时，为了验证它的真实性，它所做的一件事就是跟踪签名。它会查看SSL/TLS证书上的数字签名，并跟踪它返回到对它进行了签名的中间根。然后，它会查看该中间根的数字签名，并跟踪它返回到对该中间体进行了签名的证书。如此这样，直到最终到达其信任存储库中的一个根CA证书为止。
如果不能做到这一点，证书链通常是不完整的，这意味着浏览器无法定位其中一个中间体，SSL/TLS就会握手失败。要解决这个问题，你需要找到并安装丢失的中间证书。根据你所购买证书的供应商，证书的中间体应该可以在其网站上找到。
过期/撤销的证书
虽然当前SSL/TLS生态系统中的撤销流程还有很多不足之处，但是在某些情况中，浏览器仍然会看到证书已被撤销，并因此使得握手失败。更多的时候，这是证书过期的结果。
SSL/TLS证书过期有两个原因：
现在，SSL/TLS证书最大的有效期为两年（27个月，因为CA允许你从以前的证书最多结转3个月）。最终，它可能短至6个月。这意味着你需要定期置换证书。如果你忘记了，这可能就是SSL/TLS握手失败的原因。只需获取一个有效的证书并安装它，就可以解决你的问题。
自签名替换
在公共互联网上，如果客户端没有在其根存储中手动安装你的私有根，那么自签名证书将100%返回错误。但是，在内部网络中，自签名证书相当常见。如果置换的次数足够多，就会产生问题。
大多数浏览器都会对证书进行缓存,因此在返回网站的时候，握手流程就会更快速，但是如果你定期生成新证书,从而不断地把这些新生成的证书添加到本地数据库，那么就会导致混乱局面的发生,最终浏览器就会因挣扎于路径构建而崩溃掉。
支持SNI的服务器
这更多的是一个存在于不同设备之间的内部问题，但有时，当客户端与SNI（服务器名称指示）服务器进行通信时，如果系统不支持SNI，SSL/TLS握手也会失败。
你需要做的第一件事是识别所涉及的服务器的主机名和端口号，并确保启用了SNI，以及它正在进行所需的通信。同样，这通常不是一个面向公众的问题，有时问题来自于内部。
不应当做的事——不要奖赏糟糕的SSL/TLS实现
很多时候，网站所有者都不想有所改变，直到问题无法再进行忽视。虽然在客户端可以修复部分SSL/TLS握手失败错误，但通常这一个过程都是在服务器端进行的。
这意味着作为一个普通的互联网用户，你的选择是有限的。最好的方法是将问题告知网站所有者，等待他们修复。如果他们没有修复，那么停止使用该网站可能是十分明智的。访问网站时，有一些事情你绝对不应当做：
如果网站不能提供安全的浏览体验，你就不应当访问它。
Savemyname,email,andwebsiteinthisbrowserforthenexttimeIcomment.