此页面由 Cloud Translation API 翻译。

TLS/SSL 握手失败

<ph type="x-smartling-placeholder"></ph> 您正在查看 Apigee Edge 文档。
转到 Apigee X 文档。信息

问题

如果客户端和服务器无法使用 TLS/SSL 协议。如果 Apigee Edge 发生此错误，客户端应用会收到 HTTP 状态 503 以及消息服务不可用。您在出现 TLS/SSL 握手失败的任何 API 调用后都会看到此错误。

错误消息

HTTP/1.1 503 Service Unavailable

当 TLS/SSL 握手失败时，您也会看到此错误消息：

Received fatal alert: handshake_failure

可能的原因

TLS（传输层安全协议，其前身是 SSL）是在网络服务器和 Web 客户端（例如浏览器或应用）之间建立加密链接。握手是可让 TLS/SSL 客户端和服务器建立一组密钥的过程它们可以进行通信。在此过程中，客户端和服务器会：

同意要使用的协议版本。
选择要使用的加密算法。
通过交换和验证数字证书来相互进行身份验证。

如果 TLS/SSL 握手成功，则 TLS/SSL 客户端和服务器会将数据传输到安全地访问文件否则，如果 TLS/SSL 握手失败，则连接会终止，客户端收到 503 Service Unavailable 错误。

导致 TLS/SSL 握手失败的可能原因如下：

原因	说明	谁可以执行问题排查步骤
协议不匹配	服务器不支持客户端使用的协议。	私有云和公有云用户
加密套件不匹配	服务器不支持客户端使用的加密套件。	私有云和公有云用户
证书不正确	客户端所用网址中的主机名与证书中的主机名不匹配存储在服务器端。	私有云和公有云用户
	不完整或无效的证书链存储在客户端或服务器端。	私有云和公有云用户
	客户端向服务器或从服务器发送的证书不正确或已过期。	私有云和公有云用户
已启用 SNI 的服务器	后端服务器已启用服务器名称指示 (SNI)；但客户端无法与 SNI 服务器。	仅限 Private Cloud 用户

协议不匹配

如果客户端使用的协议不受服务器。另请参阅 <ph type="x-smartling-placeholder"></ph> 了解北向和南向连接。

诊断

确定错误发生在北向还是南向连接。如需进一步的指导，决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源。
运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息： <ph type="x-smartling-placeholder">
- 如果您是 Private Cloud 用户，则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用（对于传入、或北向连接）或消息处理器（用于传出或南向连接）。服务器可以是边缘路由器传入或北向连接）或后端服务器（针对传出或南向连接）。
- 如果您是公有云用户，则可以收集 tcpdump 数据仅在客户端应用（针对传入或北向连接）或后端服务器上（针对传出或南向连接），因为您无法访问边缘路由器或消息处理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
请参阅 tcpdump 数据的详细信息，详细了解如何使用 tcpdump 命令。
使用 Wireshark 工具分析 tcpdump 数据或类似工具
以下是对 <ph type="x-smartling-placeholder"></ph> tcpdump： <ph type="x-smartling-placeholder">
- 在本示例中，消息处理器和后端服务器（传出或南向连接）。
- 下面 tcpdump 输出中的消息 #4 显示消息处理器（源）发送了 “Client Hello”将消息发送到后端服务器（目标）。
- 如果您选择 Client Hello 消息，则表明消息处理器正在使用 TLSv1.2 协议，如下所示：
- 消息 #5 显示后端服务器确认“Client Hello”消息来自消息处理器
- 后端服务器会立即向消息处理器（消息 6）。这意味着 TLS/SSL 握手失败，连接将。
- 对消息 6 的进一步研究表明，TLS/SSL 握手失败的原因是，后端服务器仅支持如下所示的 TLSv1.0 协议：
- 由于消息处理器和后端服务器，则后端服务器发送了以下消息：Fatal Alert Message: Close 通知。

分辨率

消息处理器在 Java 8 上运行，默认情况下使用 TLSv1.2 协议。如果后端服务器不支持 TLSv1.2 协议，您可以采用以下某个步骤来解决问题此问题：

升级后端服务器以支持 TLSv1.2 协议。我们建议采用此解决方案那么 TLSv1.2 协议就更加安全
如果由于某种原因无法立即升级后端服务器，您可以强制消息处理器使用 TLSv1.0 协议与发送到后端服务器： <ph type="x-smartling-placeholder">
1. 如果您未在代理的 TargetEndpoint 定义中指定目标服务器，那么请将将 Protocol 元素设置为 TLSv1.0，如下所示如下：
```
<TargetEndpoint name="default">
 …
 <HTTPTargetConnection>
   <SSLInfo>
       <Enabled>true</Enabled>
       <Protocols>
           <Protocol>TLSv1.0</Protocol>
       </Protocols>
   </SSLInfo>
   <URL>https://myservice.com</URL>
 </HTTPTargetConnection>
 …
</TargetEndpoint>
```
2. 如果您配置了 <ph type="x-smartling-placeholder"></ph> 目标服务器，然后使用 <ph type="x-smartling-placeholder"></ph> 此 Management API 将协议设置为在目标服务器配置。

加密方式不匹配

如果客户端使用的加密套件算法不是 TLS/SSL 握手，。另请参阅了解北向和南向连接。

诊断

确定错误是否发生于北向或南向连接。有关做出此决定的进一步指导，请参阅确定问题的根源。
运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息： <ph type="x-smartling-placeholder">
- 如果您是 Private Cloud 用户，则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用（对于传入、或北向连接）或消息处理器（用于传出或南向连接）。服务器可以是边缘路由器传入或北向连接）或后端服务器（针对传出或南向连接）。
- 如果您是公有云用户，则可以收集 tcpdump 数据仅在客户端应用（针对传入或北向连接）或后端服务器上（针对传出或南向连接），因为您无法访问边缘路由器或消息处理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
请参阅 tcpdump 数据的详细信息，详细了解如何使用 tcpdump 命令。
使用 Wireshark 工具分析 tcpdump 数据或其他任何您熟悉的工具
以下是使用 Wireshark 对 tcpdump 输出进行分析的示例： <ph type="x-smartling-placeholder">
- 在此例中，TLS/SSL 握手故障在客户端应用和边缘路由器（北向连接）。在 Edge 上收集 tcpdump 输出路由器。
- 以下 tcpdump 输出中的消息 #4 显示客户端应用（来源）发送了 “Client Hello”消息发送到边缘路由器（目标）。
- 选择 Client Hello 消息显示客户端应用正在使用 TLSv1.2 协议。
- 消息 #5 显示边缘路由器确认“Client Hello”消息来自与客户端应用通信
- 边缘路由器会立即向（消息 #6）。这意味着 TLS/SSL 握手失败，且连接将会关闭。
- 对消息 6 进行深入研究会显示以下信息： <ph type="x-smartling-placeholder">
  - 边缘路由器支持 TLSv1.2 协议。这意味着，该协议与在客户端应用与边缘路由器之间移动流量。
  - 但是，边缘路由器仍会发送严重警报：握手失败，如以下屏幕截图所示：
- 该错误可能是以下某个问题导致的： <ph type="x-smartling-placeholder">
  - 客户端应用未使用边缘路由器。
  - 边缘路由器已启用 SNI，但客户端应用未发送服务器名称。
- tcpdump 输出中的消息 #4 列出了客户端支持的加密套件算法如下所示：
- 以下页面中列出了边缘路由器支持的加密套件算法： /opt/nginx/conf.d/0-default.conf 文件。在此示例中，边缘路由器仅支持高加密套件算法。
- 客户端应用未使用任何高加密加密套件算法。这种不匹配是导致 TLS/SSL 握手失败。
- 由于边缘路由器已启用 SNI，因此向下滚动到 tcpdump 输出中的消息 #4 并确认客户端应用正确发送服务器名称，如如下图所示：
- 如果此名称有效，则可以推断出 TLS/SSL 握手失败这是因为客户端应用使用的加密套件算法不受边缘路由器

分辨率

您必须确保客户端使用的是。为了解决上一课中所述的问题，诊断部分，下载并安装 <ph type="x-smartling-placeholder"></ph> Java Cryptography Extension (JCE) 软件包，并将其包含在 Java 代码中以支持高加密套件算法。

证书不正确

如果您在密钥库/信任库中的证书不正确，则 TLS/SSL 握手失败。在 Apigee Edge 中的传入（北向）或传出（南向）连接。另请参阅 <ph type="x-smartling-placeholder"></ph> 了解北向和南向连接。

如果问题是北向，您可能会看到不同的错误消息具体取决于根本原因。

以下部分列出了示例错误消息以及诊断和解决此问题的步骤问题。

错误消息

根据 TLS/SSL 握手失败的原因，您可能会看到不同的错误消息。以下是您在调用 API 代理时可能会看到的示例错误消息：

* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html

可能的原因

导致此问题的常见原因包括：

原因	说明	谁可以执行问题排查步骤
主机名不匹配	网址中使用的主机名和路由器密钥库中的证书匹配。例如，如果网址中使用的主机名是 `myorg.domain.com`，而证书的 CN 中的主机名为 `CN=something.domain.com.`	Edge 私有云和公有云用户
证书不完整或不正确链	证书链不完整或不正确。	仅面向 Edge 私有云和公有云用户
服务器或客户端	服务器或客户端在北向或南向连接	Edge Private Cloud 和 Edge 公有云用户

主机名不匹配

诊断

请记下以下 Edge Management API 调用所返回网址中使用的主机名：

curl -v https://myorg.domain.com/v1/getinfo

例如：

curl -v https://api.enterprise.apigee.com/v1/getinfo

获取存储在特定密钥库中的证书中使用的 CN。您可以使用以下 Edge Management API 来获取证书的详细信息： <ph type="x-smartling-placeholder">

<ph type="x-smartling-placeholder"></ph> 在密钥库中获取证书名称：

如果您是 Private Cloud 用户，请按如下方式使用 Management API：

curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

如果您是公有云用户，请按如下方式使用 Management API：

curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs

<ph type="x-smartling-placeholder"></ph> 使用 Edge Management API 在密钥库中获取证书的详细信息。

如果您是 Private Cloud 用户：

curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

如果您是公有云用户：

curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name

证书示例：

"certInfo": [
    {
      "basicConstraints": "CA:FALSE",
      "expiryDate": 1456258950000,
      "isValid": "No",
      "issuer": "SERIALNUMBER=07969287, CN=Go Daddy Secure Certification Authority, OU=http://certificates.godaddy.com/repository, O=\"GoDaddy.com, Inc.\", L=Scottsdale, ST=Arizona, C=US",
      "publicKey": "RSA Public Key, 2048 bits",
      "serialNumber": "07:bc:a7:39:03:f1:56",
      "sigAlgName": "SHA1withRSA",
      "subject": "CN=something.domain.com, OU=Domain Control Validated, O=something.domain.com",
      "validFrom": 1358287055000,
      "version": 3
    },

主证书中的主题名称的 CN 为 something.domain.com.

因为 API 请求网址中使用的主机名（请参阅上面的第 1 步）和主题名称不匹配，则 TLS/SSL 握手失败。

分辨率

此问题可以通过以下两种方式之一来解决：

获取主题 CN 包含通配符的证书（如果您还没有证书）证书，然后将新的完整证书链上传到密钥库。例如：
```
"subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
```
获取具有现有主题 CN 的证书（如果您还没有证书），但使用 your-org。your-domain 作为主题备用名称，然后上传完整的证书链

参考

密钥库和 Truststores

证书链不完整或不正确

诊断

获取存储在特定密钥库中的证书中使用的 CN。您可以使用以下 Edge Management API 来获取证书的详细信息： <ph type="x-smartling-placeholder">
1. <ph type="x-smartling-placeholder"></ph> 在密钥库中获取证书名称：
  
  如果您是 Private Cloud 用户：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  如果您是公有云用户：
```
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
2. <ph type="x-smartling-placeholder"></ph> 在密钥库中获取证书的详细信息：
  
  如果您是 Private Cloud 用户：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
```
  如果您是公有云用户：
```
curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
```
3. 验证证书及其链，并验证其是否符合与本文中提供的指南相比， <ph type="x-smartling-placeholder"></ph> 证书链如何发挥作用以确保其有效且完整证书链如果密钥库中存储的证书链为则会看到 TLS/SSL 握手失败。
4. 下图显示了一个具有无效证书链的示例证书，其中中间证书和根证书不匹配：

分辨率

获取包含完整且有效的证书（如果您还没有）证书链
运行以下 openssl 命令，以验证证书链是否正确并完成：
```
openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
```
将经过验证的证书链上传到密钥库。

已过期或未知服务器或客户端发送的证书

如果服务器/客户端在北向发送了错误/过期的证书或在南向连接上，则另一端（服务器/客户端）会拒绝证书也会导致 TLS/SSL 握手失败。

诊断

确定错误发生在北向还是南向连接。如需进一步的指导，决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源。
运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息： <ph type="x-smartling-placeholder">
- 如果您是 Private Cloud 用户，则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用（对于传入、或北向连接）或消息处理器（用于传出或南向连接）。服务器可以是边缘路由器传入或北向连接）或后端服务器（针对传出或南向连接）。
- 如果您是公有云用户，则可以收集 tcpdump 数据仅在客户端应用（针对传入或北向连接）或后端服务器上（针对传出或南向连接），因为您无法访问边缘路由器或消息处理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
请参阅 tcpdump 数据的详细信息，详细了解如何使用 tcpdump 命令。
tcpdump使用 Wireshark 或类似的工具
根据 tcpdump 输出，确定拒绝接收验证该证书。
您可以从 tcpdump 输出中检索从另一端发送的证书，前提是数据未经加密。这有助于比较该证书是否与证书。
查看示例 tcpdump，了解消息处理器和后端服务器
显示“证书未知”错误的示例 tcpdump
1. 消息处理器（客户端）发送“Client Hello”到后端服务器（服务器）。
2. 后端服务器发送“Server Hello”发送到消息中的消息处理器 61.
3. 它们会相互验证所使用的协议和加密套件算法。
4. 后端服务器向消息 #68 中的消息处理器。
5. 消息处理器发送严重警报“说明：证书 “未知”。
6. 在对消息 #70 进行深入研究时，没有其他详细信息。如下所示：
7. 查看消息 #68 以获取有关后端发送的证书的详细信息如下图所示：
8. 后端服务器的证书及其完整链均可用 “证书”下方部分，如上图所示。
如果路由器（北向）或如上例所示的消息处理器（南向），然后按照这些步骤： <ph type="x-smartling-placeholder">
1. 获取存储在特定信任库中的证书及其链。（参考添加到路由器的虚拟主机配置，并为配置目标端点配置消息处理器）的消息。您可以使用以下 API 获取证书： <ph type="x-smartling-placeholder">
  1. <ph type="x-smartling-placeholder"></ph> 在信任库中获取证书名称：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
```
  2. <ph type="x-smartling-placeholder"></ph> 获取信任库中的证书详细信息：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
```
2. 检查证书是否存储在路由器的信任存储区中（北向）或消息处理器（南向）与存储在客户端应用程序（北向）或目标服务器（向南）的密钥库，或者一个是从 tcpdump 输出中获取的 ID。如果不匹配，就是导致 TLS/SSL 握手失败。
如果客户端应用发现证书未知（北向）或目标服务器（南向），则请按照以下步骤操作： <ph type="x-smartling-placeholder">
1. 获取存储在特定密钥库。（请参阅路由器和目标端点的虚拟主机配置）消息处理器配置）您可以使用以下 API 获取证书详细信息： <ph type="x-smartling-placeholder">
  1. <ph type="x-smartling-placeholder"></ph> 在密钥库中获取证书名称：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  2. <ph type="x-smartling-placeholder"></ph> 在密钥库中获取证书的详细信息：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
```
2. 检查证书是否存储在路由器的密钥库中（北向）或消息处理器（南向）与存储在客户端应用程序（北向）或目标服务器（向南向），或从 tcpdump 输出中获取。如果不匹配，则这就是导致 SSL 错误的原因握手失败。
如果发现服务器/客户端发送的证书已过期，客户端/服务器拒绝证书，并且您在 tcpdump:
提醒（级别：严重，说明：证书已过期）
请验证相应主机的密钥库中的证书是否已过期。

分辨率

要解决上述示例中发现的问题，请将有效后端服务器的将证书发送给消息处理器上的受信任证书。

下表总结了根据导致此问题的原因解决问题的步骤问题。

原因	说明	解决方法
证书已过期	NorthBound <ph type="x-smartling-placeholder"> </ph> 存储在路由器密钥库的证书已过期。存储在客户端应用的密钥库中的证书已过期（双向 SSL）。	将新证书及其完整链上传到相应主机。
证书已过期	SouthBound <ph type="x-smartling-placeholder"> </ph> 存储在目标服务器的密钥库中的证书已过期。存储在消息处理器的密钥库中的证书已过期（双向 SSL）。	将新证书及其完整链上传到相应主机。
未知证书	NorthBound <ph type="x-smartling-placeholder"> </ph> 存储在客户端应用的信任库中的证书不匹配路由器证书存储在路由器信任库中的证书与客户端不匹配应用证书（双向 SSL）。	将有效证书上传到相应主机上的信任库。
未知证书	SouthBound <ph type="x-smartling-placeholder"> </ph> 存储在目标服务器的信任库中的证书与消息处理器的证书。消息处理器信任存储区中存储的证书不匹配目标服务器的证书（双向 SSL）。	将有效证书上传到相应主机上的信任库。

SNI 已启用服务器

当客户端与服务器通信时，可能会发生 TLS/SSL 握手失败名称指示 (SNI) 已启用服务器，但客户端未启用 SNI。这可能发生在北向或 Edge 中的南向连接

首先，您需要确定所用服务器的主机名和端口号，并检查它是否已启用 SNI

标识已启用 SNI 的服务器

执行 openssl 命令并尝试连接到相关的服务器主机名 (Edge 路由器或后端服务器），如下所示：

openssl s_client -connect hostname:port

您可能会获得证书，有时可能会在 openssl 命令，如下所示：

CONNECTED(00000003)
9362:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_clnt.c:593

执行 openssl 命令并尝试连接到相关的服务器主机名（边缘路由器或后端服务器）传递服务器名称，如下所示：
```
openssl s_client -connect hostname:port -servername hostname
```
如果您在第 1 步中遇到握手失败，或者在第 1 步中获得了不同的证书，并且那么就表示指定的服务器已启用 SNI。

确定服务器已启用 SNI 之后，您可以遵循以下步骤检查 TLS/SSL 握手失败是否由客户端无法与之通信 SNI 服务器。

诊断

确定错误发生在北向还是南向连接。如需进一步的指导，决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源。
运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息： <ph type="x-smartling-placeholder">
- 如果您是 Private Cloud 用户，则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用（对于传入、或北向连接）处理器（用于传出或南向连接）。服务器可以是边缘路由器传入或北向连接）或后端服务器（针对传出或南向连接）。
- 如果您是公有云用户，则可以收集 tcpdump 数据仅在客户端应用（针对传入或北向连接）或后端服务器上（针对传出或南向连接），因为您无法访问边缘路由器或消息处理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
请参阅 tcpdump 数据的详细信息，详细了解如何使用 tcpdump 命令。
使用 Wireshark 或tcpdump 类似的工具
下面是使用 Wireshark 对 tcpdump 进行分析的示例： <ph type="x-smartling-placeholder">
1. 在此示例中，TLS/SSL 握手在边缘消息之间发生失败处理器和后端服务器（南向连接）。
2. 以下 tcpdump 输出中的消息 #4 显示消息处理器（源）已发送 “Client Hello”将消息发送到后端服务器（目标）。
3. 选择“Client Hello”显示处理器使用的是 TLSv1.2 协议。
4. 消息 #4 显示后端服务器确认了“Client Hello”消息从消息处理器中进行处理
5. 后端服务器立即发送一条严重警报：握手失败（消息 5）。这意味着 TLS/SSL 握手失败，连接将关闭。
6. 查看消息 6，了解以下信息 <ph type="x-smartling-placeholder">
  - 后端服务器支持 TLSv1.2 协议。这意味着消息处理器和后端服务器之间的数据匹配。
  - 但是，后端服务器仍然会发送严重警报：握手失败，如下图所示：
7. 出现此错误的原因可能有以下几种： <ph type="x-smartling-placeholder">
  - 消息处理器未使用后端服务器
  - 后端服务器已启用 SNI，但客户端应用未发送服务器名称。
8. 更详细地查看 tcpdump 输出中的消息 #3 (Client Hello)。请注意，缺少扩展程序：server_name，如下所示：
9. 这表明消息处理器没有发送将 server_name 发送到已启用 SNI 的后端服务器。
10. 这是 TLS/SSL 握手失败的原因，服务器向消息发送严重警报：握手失败 处理器。
验证 jsse.enableSNIExtension property 在消息处理器上将 system.properties 设置为 false，以确认消息处理器无法与已启用 SNI 的服务器进行通信。

分辨率

通过执行操作步骤：

创建 /opt/apigee/customer/application/message-processor.properties 文件（如果尚未存在）。
将以下代码行添加到此文件中： conf_system_jsse.enableSNIExtension=true

对此文件的所有者执行 chown 操作，以便 apigee:apigee：

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

重启消息处理器。

/opt/apigee/apigee-service/bin/apigee-service message-processor restart

如果您有多个消息处理器，请在所有消息处理器上重复执行第 1 步到第 4 步。消息处理器。

如果您无法确定 TLS/SSL 握手失败的原因并解决问题，或者您需要任何进一步的帮助，请联系 Apigee Edge 支持。请提供关于该问题的完整详情，并附上 tcpdump 输出。

TLS/SSL 握手失败

问题

错误消息

可能的原因

协议 不匹配

诊断

分辨率

加密方式不匹配

诊断

分辨率

证书不正确

错误消息

可能的原因

主机名 不匹配

诊断

分辨率

参考

证书链不完整或不正确

诊断

分辨率

已过期或未知 服务器或客户端发送的证书

诊断

分辨率

SNI 已启用 服务器

标识已启用 SNI 的服务器

诊断

分辨率

协议不匹配

主机名不匹配

已过期或未知服务器或客户端发送的证书

SNI 已启用服务器