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 客户端和服务器建立一组密钥的过程 它们可以进行通信。在此过程中,客户端和服务器会:

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

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

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

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

协议 不匹配

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

诊断

  1. 确定错误发生在北向还是 南向连接。如需进一步的指导, 决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源
  2. 运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息: <ph type="x-smartling-placeholder">
      </ph>
    • 如果您是 Private Cloud 用户,则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。
    • 如果您是公有云用户,则可以收集 tcpdump 数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
    tcpdump -i any -s 0 host IP address -w File name
    
    请参阅 tcpdump 数据的详细信息,详细了解如何使用 tcpdump 命令。
  3. 使用 Wireshark 工具分析 tcpdump 数据 或类似工具
  4. 以下是对 <ph type="x-smartling-placeholder"></ph> tcpdump: <ph type="x-smartling-placeholder">
      </ph>
    • 在本示例中,消息处理器和 后端服务器(传出或南向连接)。
    • 下面 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 协议,您可以采用以下某个步骤来解决问题 此问题:

  1. 升级后端服务器以支持 TLSv1.2 协议。我们建议采用此解决方案 那么 TLSv1.2 协议就更加安全
  2. 如果由于某种原因无法立即升级后端服务器,您可以 强制消息处理器使用 TLSv1.0 协议与 发送到后端服务器: <ph type="x-smartling-placeholder">
      </ph>
    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 握手, 。 另请参阅 了解北向和南向连接

诊断

  1. 确定错误是否发生于 北向南向连接。 有关做出此决定的进一步指导,请参阅 确定 问题的根源
  2. 运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息: <ph type="x-smartling-placeholder">
      </ph>
    • 如果您是 Private Cloud 用户,则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。
    • 如果您是公有云用户,则可以收集 tcpdump 数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
    tcpdump -i any -s 0 host IP address -w File name
    
    请参阅 tcpdump 数据的详细信息,详细了解如何使用 tcpdump 命令。
  3. 使用 Wireshark 工具分析 tcpdump 数据 或其他任何您熟悉的工具
  4. 以下是使用 Wireshark 对 tcpdump 输出进行分析的示例: <ph type="x-smartling-placeholder">
      </ph>
    • 在此例中,TLS/SSL 握手故障在客户端应用和 边缘路由器(北向连接)。在 Edge 上收集 tcpdump 输出 路由器。
    • 以下 tcpdump 输出中的消息 #4 显示客户端应用(来源)发送了 “Client Hello”消息发送到边缘路由器(目标)。

    • 选择 Client Hello 消息显示客户端应用正在使用 TLSv1.2 协议。

    • 消息 #5 显示边缘路由器确认“Client Hello”消息来自 与客户端应用通信
    • 边缘路由器会立即向 (消息 #6)。这意味着 TLS/SSL 握手失败,且连接 将会关闭。
    • 对消息 6 进行深入研究会显示以下信息: <ph type="x-smartling-placeholder">
        </ph>
      • 边缘路由器支持 TLSv1.2 协议。这意味着,该协议与 在客户端应用与边缘路由器之间移动流量。
      • 但是,边缘路由器仍会发送严重警报:握手 失败,如以下屏幕截图所示:

    • 该错误可能是以下某个问题导致的: <ph type="x-smartling-placeholder">
        </ph>
      • 客户端应用未使用 边缘路由器。
      • 边缘路由器已启用 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 公有云用户

主机名 不匹配

诊断

  1. 请记下以下 Edge Management API 调用所返回网址中使用的主机名:
    curl -v https://myorg.domain.com/v1/getinfo
    例如:
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. 获取存储在特定密钥库中的证书中使用的 CN。您可以使用 以下 Edge Management API 来获取证书的详细信息: <ph type="x-smartling-placeholder">
      </ph>
    1. <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
      
    2. <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-orgyour-domain 作为主题备用名称,然后上传完整的 证书链

参考

密钥库和 Truststores

证书链不完整或不正确

诊断

  1. 获取存储在特定密钥库中的证书中使用的 CN。您可以使用 以下 Edge Management API 来获取证书的详细信息: <ph type="x-smartling-placeholder">
      </ph>
    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. 下图显示了一个具有无效证书链的示例证书, 其中中间证书和根证书不匹配:
    5. 颁发者和根证书的中间证书和根证书示例 主题不匹配


分辨率

  1. 获取包含完整且有效的证书(如果您还没有) 证书链
  2. 运行以下 openssl 命令,以验证证书链是否正确并 完成:
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
  3. 将经过验证的证书链上传到密钥库。

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

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

诊断

  1. 确定错误发生在北向还是 南向连接。如需进一步的指导, 决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源
  2. 运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息: <ph type="x-smartling-placeholder">
      </ph>
    • 如果您是 Private Cloud 用户,则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。
    • 如果您是公有云用户,则可以收集 tcpdump 数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
    tcpdump -i any -s 0 host IP address -w File name
    
    请参阅 tcpdump 数据的详细信息,详细了解如何使用 tcpdump 命令。
  3. tcpdump使用 Wireshark 或 类似的工具
  4. 根据 tcpdump 输出,确定拒绝接收 验证该证书。
  5. 您可以从 tcpdump 输出中检索从另一端发送的证书,前提是 数据未经加密。这有助于比较该证书是否与 证书。
  6. 查看示例 tcpdump,了解消息处理器和 后端服务器

    显示“证书未知”错误的示例 tcpdump


    1. 消息处理器(客户端)发送“Client Hello”到后端服务器 (服务器)。
    2. 后端服务器发送“Server Hello”发送到消息中的消息处理器 61.
    3. 它们会相互验证所使用的协议和加密套件算法。
    4. 后端服务器向 消息 #68 中的消息处理器。
    5. 消息处理器发送严重警报“说明:证书 “未知”
    6. 在对消息 #70 进行深入研究时,没有其他详细信息。 如下所示:


    7. 查看消息 #68 以获取有关后端发送的证书的详细信息 如下图所示:

    8. 后端服务器的证书及其完整链均可用 “证书”下方部分,如上图所示。
  7. 如果路由器(北向)或 如上例所示的消息处理器(南向),然后按照这些 步骤: <ph type="x-smartling-placeholder">
      </ph>
    1. 获取存储在特定信任库中的证书及其链。(参考 添加到路由器的虚拟主机配置,并为 配置目标端点配置 消息处理器)的消息。您可以使用以下 API 获取 证书: <ph type="x-smartling-placeholder">
        </ph>
      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 握手失败。
  8. 如果客户端应用发现证书未知(北向) 或目标服务器(南向),则请按照以下步骤操作: <ph type="x-smartling-placeholder">
      </ph>
    1. 获取存储在特定 密钥库。(请参阅路由器和目标端点的虚拟主机配置) 消息处理器配置)您可以使用以下 API 获取 证书详细信息: <ph type="x-smartling-placeholder">
        </ph>
      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 错误的原因 握手失败。
  9. 如果发现服务器/客户端发送的证书已过期, 客户端/服务器拒绝证书,并且您在 tcpdump:

    提醒(级别:严重,说明:证书已过期)

  10. 请验证相应主机的密钥库中的证书是否已过期。

分辨率

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

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

原因 说明 解决方法
证书已过期 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 的服务器

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

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

诊断

  1. 确定错误发生在北向还是 南向连接。如需进一步的指导, 决心, 参见 <ph type="x-smartling-placeholder"></ph> 确定问题根源
  2. 运行 <ph type="x-smartling-placeholder"></ph> tcpdump 实用程序收集更多信息: <ph type="x-smartling-placeholder">
      </ph>
    • 如果您是 Private Cloud 用户,则可以收集 tcpdump 将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接) 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。
    • 如果您是公有云用户,则可以收集 tcpdump 数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
    tcpdump -i any -s 0 host IP address -w File name
    
    请参阅 tcpdump 数据的详细信息,详细了解如何使用 tcpdump 命令。
  3. 使用 Wiresharktcpdump 类似的工具
  4. 下面是使用 Wireshark 对 tcpdump 进行分析的示例: <ph type="x-smartling-placeholder">
      </ph>
    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">
        </ph>
      • 后端服务器支持 TLSv1.2 协议。这意味着 消息处理器和后端服务器之间的数据匹配。
      • 但是,后端服务器仍然会发送严重警报:握手 失败,如下图所示:

    7. 出现此错误的原因可能有以下几种: <ph type="x-smartling-placeholder">
        </ph>
      • 消息处理器未使用 后端服务器
      • 后端服务器已启用 SNI,但客户端应用未发送 服务器名称。
    8. 更详细地查看 tcpdump 输出中的消息 #3 (Client Hello)。请注意, 缺少扩展程序:server_name,如下所示:

    9. 这表明消息处理器没有发送 将 server_name 发送到已启用 SNI 的后端服务器。
    10. 这是 TLS/SSL 握手失败的原因, 服务器向消息发送严重警报:握手失败 处理器。
  5. 验证 jsse.enableSNIExtension property 在消息处理器上将 system.properties 设置为 false,以确认 消息处理器无法与已启用 SNI 的服务器进行通信。

分辨率

通过执行 操作步骤:

  1. 创建 /opt/apigee/customer/application/message-processor.properties 文件(如果尚未存在)。
  2. 将以下代码行添加到此文件中: conf_system_jsse.enableSNIExtension=true
  3. 对此文件的所有者执行 chown 操作,以便 apigee:apigee
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. 重启消息处理器。
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. 如果您有多个消息处理器,请在所有消息处理器上重复执行第 1 步到第 4 步。 消息处理器。

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