<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">
- </ph>
- 如果您是 Private Cloud 用户,则可以收集
tcpdump
将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。 - 如果您是公有云用户,则可以收集
tcpdump
数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
请参阅 tcpdump 数据的详细信息,详细了解如何使用tcpdump -i any -s 0 host IP address -w File name
tcpdump
命令。 - 如果您是 Private Cloud 用户,则可以收集
- 使用 Wireshark 工具分析
tcpdump
数据 或类似工具 - 以下是对
<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 协议,您可以采用以下某个步骤来解决问题 此问题:
- 升级后端服务器以支持 TLSv1.2 协议。我们建议采用此解决方案 那么 TLSv1.2 协议就更加安全
- 如果由于某种原因无法立即升级后端服务器,您可以
强制消息处理器使用 TLSv1.0 协议与
发送到后端服务器:
<ph type="x-smartling-placeholder">
- </ph>
- 如果您未在代理的 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>
- 如果您配置了 <ph type="x-smartling-placeholder"></ph> 目标服务器,然后使用 <ph type="x-smartling-placeholder"></ph> 此 Management API 将协议设置为在 目标服务器配置。
- 如果您未在代理的 TargetEndpoint 定义中指定目标服务器,那么请将
将
加密方式不匹配
如果客户端使用的加密套件算法不是 TLS/SSL 握手, 。 另请参阅 了解北向和南向连接。
诊断
- 确定错误是否发生于 北向或南向连接。 有关做出此决定的进一步指导,请参阅 确定 问题的根源。
- 运行
<ph type="x-smartling-placeholder"></ph>
tcpdump 实用程序收集更多信息:
<ph type="x-smartling-placeholder">
- </ph>
- 如果您是 Private Cloud 用户,则可以收集
tcpdump
将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。 - 如果您是公有云用户,则可以收集
tcpdump
数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
请参阅 tcpdump 数据的详细信息,详细了解如何使用tcpdump -i any -s 0 host IP address -w File name
tcpdump
命令。 - 如果您是 Private Cloud 用户,则可以收集
- 使用 Wireshark 工具分析
tcpdump
数据 或其他任何您熟悉的工具 - 以下是使用 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 握手失败 这是因为客户端应用使用的加密套件算法不受 边缘路由器
- 在此例中,TLS/SSL 握手故障在客户端应用和
边缘路由器(北向连接)。在 Edge 上收集
分辨率
您必须确保客户端使用的是 。为了解决上一课中所述的问题, 诊断部分,下载并安装 <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>
-
<ph type="x-smartling-placeholder"></ph>
在密钥库中获取证书名称:
如果您是 Private Cloud 用户,请按如下方式使用 Management API:
如果您是公有云用户,请按如下方式使用 Management API: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
-
<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 握手失败。
-
<ph type="x-smartling-placeholder"></ph>
在密钥库中获取证书名称:
分辨率
此问题可以通过以下两种方式之一来解决:
- 获取主题 CN 包含通配符的证书(如果您还没有证书)
证书,然后将新的完整证书链上传到密钥库。例如:
"subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
- 获取具有现有主题 CN 的证书(如果您还没有证书),但使用 your-org。your-domain 作为主题备用名称,然后上传完整的 证书链
参考
证书链不完整或不正确
诊断
- 获取存储在特定密钥库中的证书中使用的 CN。您可以使用
以下 Edge Management API 来获取证书的详细信息:
<ph type="x-smartling-placeholder">
- </ph>
-
<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
-
<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
- 验证证书及其链,并验证其是否符合 与本文中提供的指南相比, <ph type="x-smartling-placeholder"></ph> 证书链如何发挥作用以确保其有效且完整 证书链如果密钥库中存储的证书链为 则会看到 TLS/SSL 握手 失败。
- 下图显示了一个具有无效证书链的示例证书, 其中中间证书和根证书不匹配:
颁发者和根证书的中间证书和根证书示例 主题不匹配
-
<ph type="x-smartling-placeholder"></ph>
在密钥库中获取证书名称:
分辨率
- 获取包含完整且有效的证书(如果您还没有) 证书链
- 运行以下 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">
- </ph>
- 如果您是 Private Cloud 用户,则可以收集
tcpdump
将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接)或消息 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。 - 如果您是公有云用户,则可以收集
tcpdump
数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
请参阅 tcpdump 数据的详细信息,详细了解如何使用tcpdump -i any -s 0 host IP address -w File name
tcpdump
命令。 - 如果您是 Private Cloud 用户,则可以收集
tcpdump
使用 Wireshark 或 类似的工具- 根据
tcpdump
输出,确定拒绝接收 验证该证书。 - 您可以从
tcpdump
输出中检索从另一端发送的证书,前提是 数据未经加密。这有助于比较该证书是否与 证书。 - 查看示例
tcpdump
,了解消息处理器和 后端服务器显示“证书未知”错误的示例
tcpdump
- 消息处理器(客户端)发送“Client Hello”到后端服务器 (服务器)。
- 后端服务器发送“Server Hello”发送到消息中的消息处理器 61.
- 它们会相互验证所使用的协议和加密套件算法。
- 后端服务器向 消息 #68 中的消息处理器。
- 消息处理器发送严重警报“说明:证书 “未知”。
- 在对消息 #70 进行深入研究时,没有其他详细信息。
如下所示:
- 查看消息 #68 以获取有关后端发送的证书的详细信息 如下图所示:
- 后端服务器的证书及其完整链均可用 “证书”下方部分,如上图所示。
- 如果路由器(北向)或
如上例所示的消息处理器(南向),然后按照这些
步骤:
<ph type="x-smartling-placeholder">
- </ph>
- 获取存储在特定信任库中的证书及其链。(参考
添加到路由器的虚拟主机配置,并为 配置目标端点配置
消息处理器)的消息。您可以使用以下 API 获取
证书:
<ph type="x-smartling-placeholder">
- </ph>
-
<ph type="x-smartling-placeholder"></ph>
在信任库中获取证书名称:
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
-
<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
-
<ph type="x-smartling-placeholder"></ph>
在信任库中获取证书名称:
- 检查证书是否存储在路由器的信任存储区中(北向)或
消息处理器(南向)与存储在
客户端应用程序(北向)或目标服务器(向南)的密钥库,或者
一个是从
tcpdump
输出中获取的 ID。如果不匹配,就是导致 TLS/SSL 握手失败。
- 获取存储在特定信任库中的证书及其链。(参考
添加到路由器的虚拟主机配置,并为 配置目标端点配置
消息处理器)的消息。您可以使用以下 API 获取
证书:
<ph type="x-smartling-placeholder">
- 如果客户端应用发现证书未知(北向)
或目标服务器(南向),则请按照以下步骤操作:
<ph type="x-smartling-placeholder">
- </ph>
- 获取存储在特定
密钥库。(请参阅路由器和目标端点的虚拟主机配置)
消息处理器配置)您可以使用以下 API 获取
证书详细信息:
<ph type="x-smartling-placeholder">
- </ph>
-
<ph type="x-smartling-placeholder"></ph>
在密钥库中获取证书名称:
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
-
<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
-
<ph type="x-smartling-placeholder"></ph>
在密钥库中获取证书名称:
- 检查证书是否存储在路由器的密钥库中(北向)或
消息处理器(南向)与存储在
客户端应用程序(北向)或目标服务器(向南向),或
从
tcpdump
输出中获取。如果不匹配,则这就是导致 SSL 错误的原因 握手失败。
- 获取存储在特定
密钥库。(请参阅路由器和目标端点的虚拟主机配置)
消息处理器配置)您可以使用以下 API 获取
证书详细信息:
<ph type="x-smartling-placeholder">
- 如果发现服务器/客户端发送的证书已过期,
客户端/服务器拒绝证书,并且您在
tcpdump
:提醒(级别:严重,说明:证书已过期)
- 请验证相应主机的密钥库中的证书是否已过期。
分辨率
要解决上述示例中发现的问题,请将有效后端服务器的 将证书发送给消息处理器上的受信任证书。
下表总结了根据导致此问题的原因解决问题的步骤 问题。
原因 | 说明 | 解决方法 |
证书已过期 |
NorthBound
<ph type="x-smartling-placeholder">
|
将新证书及其完整链上传到相应 主机。 |
SouthBound
<ph type="x-smartling-placeholder">
|
将新证书及其完整链上传到相应 主机。 | |
未知证书 |
NorthBound
<ph type="x-smartling-placeholder">
|
将有效证书上传到相应主机上的信任库。 |
SouthBound
<ph type="x-smartling-placeholder">
|
将有效证书上传到相应主机上的信任库。 |
SNI 已启用 服务器
当客户端与服务器通信时,可能会发生 TLS/SSL 握手失败 名称指示 (SNI) 已启用 服务器,但客户端未启用 SNI。这可能发生在北向或 Edge 中的南向连接
首先,您需要确定所用服务器的主机名和端口号,并检查 它是否已启用 SNI
标识已启用 SNI 的服务器
- 执行
openssl
命令并尝试连接到相关的服务器主机名 (Edge 路由器或后端服务器),如下所示: 您可能会获得证书,有时可能会在 openssl 命令,如下所示:openssl s_client -connect hostname:port
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">
- </ph>
- 如果您是 Private Cloud 用户,则可以收集
tcpdump
将数据存储在相关客户端或服务器上客户端可以是客户端应用(对于传入、 或北向连接) 处理器(用于传出或南向连接)。服务器可以是边缘路由器 传入或北向连接)或后端服务器 (针对传出或南向连接)。 - 如果您是公有云用户,则可以收集
tcpdump
数据仅在客户端应用(针对传入或北向连接)或后端服务器上 (针对传出或南向连接),因为您 无法访问边缘路由器或消息处理器。
请参阅 tcpdump 数据的详细信息,详细了解如何使用tcpdump -i any -s 0 host IP address -w File name
tcpdump
命令。 - 如果您是 Private Cloud 用户,则可以收集
- 使用 Wireshark 或
tcpdump
类似的工具 - 下面是使用 Wireshark 对
tcpdump
进行分析的示例: <ph type="x-smartling-placeholder">- </ph>
- 在此示例中,TLS/SSL 握手在边缘消息之间发生失败 处理器和后端服务器(南向连接)。
- 以下
tcpdump
输出中的消息 #4 显示消息处理器(源)已发送 “Client Hello”将消息发送到后端服务器(目标)。 - 选择“Client Hello”显示 处理器使用的是 TLSv1.2 协议。
- 消息 #4 显示后端服务器确认了“Client Hello”消息 从消息处理器中进行处理
- 后端服务器立即发送一条严重警报:握手 失败(消息 5)。这意味着 TLS/SSL 握手 失败,连接将关闭。
- 查看消息 6,了解以下信息
<ph type="x-smartling-placeholder">
- </ph>
- 后端服务器支持 TLSv1.2 协议。这意味着 消息处理器和后端服务器之间的数据匹配。
- 但是,后端服务器仍然会发送严重警报:握手 失败,如下图所示:
- 出现此错误的原因可能有以下几种:
<ph type="x-smartling-placeholder">
- </ph>
- 消息处理器未使用 后端服务器
- 后端服务器已启用 SNI,但客户端应用未发送 服务器名称。
- 更详细地查看
tcpdump
输出中的消息 #3 (Client Hello)。请注意, 缺少扩展程序:server_name,如下所示: - 这表明消息处理器没有发送 将 server_name 发送到已启用 SNI 的后端服务器。
- 这是 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
输出。