Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

TLS/SSL 握手失敗

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

如果用戶端和伺服器無法使用 TLS/SSL 通訊協定建立通訊，就會發生 TLS/SSL 握手失敗。在 Apigee Edge 中發生這項錯誤時，用戶端應用程式會收到 HTTP 狀態 503，並顯示「Service Unavailable」(服務無法使用) 訊息。如果 API 呼叫發生傳輸層安全標準 (TLS)/安全通訊端層 (SSL) 握手失敗，就會看到這項錯誤。

錯誤訊息

HTTP/1.1 503 Service Unavailable

如果發生 TLS/SSL 握手失敗的情況，您也可能會看到這則錯誤訊息：

Received fatal alert: handshake_failure

可能原因

TLS (傳輸層安全標準，前身為安全資料傳輸層：SSL) 是標準安全技術，用於在網路伺服器和網頁用戶端 (例如瀏覽器或應用程式) 之間建立已加密連結。握手程序可讓傳輸層安全標準：TLS/安全資料傳輸層：SSL 用戶端和伺服器建立一組私密金鑰，以便進行通訊。在這項程序中，用戶端和伺服器會執行下列動作：

同意要使用的通訊協定版本。
選取要使用的加密演算法。
交換並驗證數位憑證，相互驗證身分。

如果 TLS/SSL 握手成功，TLS/SSL 用戶端和伺服器就會彼此安全地傳輸資料。否則，如果發生 TLS/SSL 交握失敗，連線會終止，且用戶端會收到 503 Service Unavailable 錯誤。

TLS/SSL 握手失敗的可能原因如下：

原因	說明	誰可以執行疑難排解步驟
通訊協定不符	伺服器不支援用戶端使用的通訊協定。	私有雲和公有雲使用者
加密套件不符	伺服器不支援用戶端使用的加密套件。	私有雲和公有雲使用者
憑證不正確	用戶端使用的網址中的主機名稱，與伺服器端儲存的憑證中的主機名稱不符。	私有雲和公有雲使用者
	用戶端或伺服器端儲存的憑證鏈結不完整或無效。	私有雲和公有雲使用者
	用戶端傳送給伺服器或伺服器傳送給用戶端的憑證不正確或已過期。	私有雲和公有雲使用者
已啟用 SNI 的伺服器	後端伺服器已啟用伺服器名稱指示 (SNI)，但用戶端無法與 SNI 伺服器通訊。	僅限私有雲使用者

通訊協定不符

如果用戶端使用的通訊協定在傳入 (北向) 或傳出 (南向) 連線中，不支援伺服器，就會發生 TLS/SSL 交握失敗。另請參閱「瞭解北向和南向連線」。

診斷

判斷錯誤是發生在北向或南向連線。如需進一步瞭解如何判斷問題來源，請參閱「判斷問題來源」。
執行 tcpdump 公用程式，收集更多資訊：
- 如果您是私有雲使用者，可以在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (適用於連入或北向連線)，也可以是訊息處理器 (適用於連出或南向連線)。根據步驟 1 的判斷結果，伺服器可以是邊緣路由器 (適用於連入或北向連線)，也可以是後端伺服器 (適用於連出或南向連線)。
- 如果您是公有雲使用者，則只能在用戶端應用程式 (適用於連入或北向連線) 或後端伺服器 (適用於連出或南向連線) 收集 tcpdump 資料，因為您無法存取 Edge 路由器或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
如要進一步瞭解如何使用 tcpdump 指令，請參閱 tcpdump 資料。
使用 Wireshark 工具或類似工具分析 tcpdump 資料。
以下是使用 Wireshark 分析 tcpdump 的範例：
- 在本例中，訊息處理器與後端伺服器之間發生 TLS/SSL 交握失敗 (外送或南向連線)。
- 下方 tcpdump 輸出內容中的訊息 #4 顯示，訊息處理器 (來源) 已將「Client Hello」訊息傳送至後端伺服器 (目的地)。
- 如果選取 Client Hello 訊息，系統會顯示訊息處理器使用 TLSv1.2 通訊協定，如下所示：
- 訊息 #5 顯示後端伺服器確認訊息處理器的「Client Hello」訊息。
- 後端伺服器會立即將「Fatal Alert : Close Notify」傳送至訊息處理器 (訊息 #6)。這表示 TLS/SSL 握手失敗，連線將會關閉。
- 進一步查看郵件 #6，發現傳輸層安全標準 (TLS)/安全通訊端層 (SSL) 握手失敗的原因是後端伺服器僅支援 TLSv1.0 通訊協定，如下所示：
- 由於訊息處理器和後端伺服器使用的通訊協定不一致，後端伺服器傳送了以下訊息：Fatal Alert Message: Close Notify。

解析度

訊息處理器會在 Java 8 上執行，且預設使用 TLSv1.2 通訊協定。如果後端伺服器不支援 TLSv1.2 通訊協定，請採取下列其中一個步驟解決這個問題：

升級後端伺服器，支援 TLSv1.2 通訊協定。建議採用這項解決方案，因為 TLSv1.2 通訊協定更安全。
如果因為某些原因無法立即升級後端伺服器，可以按照下列步驟，強制訊息處理器使用 TLSv1.0 通訊協定與後端伺服器通訊：
1. 如果您未在 Proxy 的 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. 如果您為 Proxy 設定目標伺服器，請使用管理 API，在特定目標伺服器設定中將通訊協定設為 TLSv1.0。

密碼不符

如果用戶端使用的加密套件演算法不支援 Apigee Edge 的連入 (北向) 或連出 (南向) 連線，您可能會看到 TLS/SSL 交握失敗。另請參閱「瞭解北向和南向連線」。

診斷

判斷錯誤發生在北向或南向連線。如需進一步瞭解如何判斷問題來源，請參閱「判斷問題來源」。
執行 tcpdump 公用程式，收集更多資訊：
- 如果您是私有雲使用者，可以在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (適用於連入或北向連線)，也可以是訊息處理器 (適用於連出或南向連線)。根據步驟 1 的判斷結果，伺服器可以是邊緣路由器 (適用於連入或北向連線)，也可以是後端伺服器 (適用於連出或南向連線)。
- 如果您是公有雲使用者，則只能在用戶端應用程式 (適用於連入或北向連線) 或後端伺服器 (適用於連出或南向連線) 收集 tcpdump 資料，因為您無法存取 Edge 路由器或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
如要進一步瞭解如何使用 tcpdump 指令，請參閱 tcpdump 資料。
使用 Wireshark 工具或您熟悉的任何其他工具，分析 tcpdump 資料。
以下是使用 Wireshark 分析 tcpdump 輸出內容的範例：
- 在本範例中，用戶端應用程式與 Edge 路由器 (北向連線) 之間發生 TLS/SSL 交握失敗。tcpdump 輸出內容是在 Edge 路由器上收集。
- 下方 tcpdump 輸出內容中的訊息 #4 顯示，用戶端應用程式 (來源) 將「Client Hello」訊息傳送至 Edge 路由器 (目的地)。
- 選取「Client Hello」訊息，即可查看用戶端應用程式使用的 TLSv1.2 通訊協定。
- 訊息 #5 顯示 Edge 路由器確認來自用戶端應用程式的「Client Hello」訊息。
- Edge 路由器會立即將「Fatal Alert : Handshake Failure」傳送至用戶端應用程式 (訊息 #6)。這表示 TLS/SSL 握手失敗，連線將會關閉。
- 進一步查看訊息 #6，會顯示下列資訊：
  - Edge 路由器支援 TLSv1.2 通訊協定。也就是說，用戶端應用程式和 Edge 路由器之間的通訊協定相符。
  - 不過，Edge 路由器仍會將「Fatal Alert: Handshake Failure」傳送至用戶端應用程式，如下方螢幕截圖所示：
- 這個錯誤可能是由下列其中一項問題造成：
  - 用戶端應用程式未採用 Edge 路由器支援的加密套件演算法。
  - Edge Router 已啟用 SNI，但用戶端應用程式未傳送伺服器名稱。
- tcpdump 輸出內容中的訊息 #4 會列出用戶端應用程式支援的加密套件演算法，如下所示：
- Edge 路由器支援的加密套件演算法清單列於 /opt/nginx/conf.d/0-default.conf 檔案中。在本範例中，Edge 路由器僅支援高加密加密套件演算法。
- 用戶端應用程式未使用任何高加密加密套件演算法。這個不相符問題是造成 TLS/SSL 握手失敗的原因。
- 由於 Edge 路由器已啟用 SNI，請向下捲動至 tcpdump 輸出內容中的訊息 #4，並確認用戶端應用程式正確傳送伺服器名稱，如下圖所示：
- 如果這個名稱有效，您可以推斷 TLS/SSL 交握失敗，是因為用戶端應用程式使用的密碼編譯套件演算法不受 Edge 路由器支援。

解析度

請務必確認用戶端使用的加密套件演算法是伺服器支援的演算法。如要解決上一個「診斷」一節所述的問題，請下載並安裝 Java Cryptography Extension (JCE) 套件，然後將其納入 Java 安裝作業，以支援高加密加密套件演算法。

憑證不正確

如果金鑰儲存區/信任儲存區中的憑證有誤，Apigee Edge 的連入 (北向) 或連出 (南向) 連線就會發生 TLS/SSL 交握失敗的情況。另請參閱「瞭解北向和南向連線」。

如果問題是北向，您可能會看到不同的錯誤訊息，具體取決於根本原因。

下列各節列出錯誤訊息範例，以及診斷和解決這個問題的步驟。

錯誤訊息

視 TLS/SSL 交握失敗的原因而定，您可能會看到不同的錯誤訊息。以下是呼叫 API Proxy 時可能出現的錯誤訊息範例：

* 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 Public Cloud 使用者

主機名稱不符

診斷

請注意下列 Edge 管理 API 呼叫傳回的網址所用的主機名稱：

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

例如：

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

取得儲存在特定 KeyStore 中的憑證所使用的 CN。您可以使用下列 Edge 管理 API 取得憑證詳細資料：

在金鑰儲存區中取得憑證名稱：

如果您是私有雲使用者，請使用 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

使用 Edge 管理 API 取得 KeyStore 中的憑證詳細資料。

如果您是 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 具有萬用字元憑證的憑證 (如果沒有)，然後將新的完整憑證鏈上傳至 KeyStore。例如：
```
"subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
```
取得現有主體 CN 的憑證 (如果還沒有)，但請使用 your-org。your-domain 做為主體替代名稱，然後將完整的憑證鏈上傳至金鑰儲存區。

參考資料

金鑰儲存區和信任儲存區

憑證鏈結不完整或有誤

診斷

取得儲存在特定 KeyStore 中的憑證所使用的 CN。您可以使用下列 Edge 管理 API 取得憑證詳細資料：
1. 取得 KeyStore 中的憑證名稱：
  
  如果您是 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. 取得金鑰儲存庫中憑證的詳細資料：
  
  如果您是 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. 驗證憑證及其鏈結，並確認憑證符合「憑證鏈結的運作方式」一文中的指南，確保憑證鏈結有效且完整。如果金鑰儲存區中儲存的憑證鏈結不完整或無效，就會看到 TLS/SSL 交握失敗訊息。
4. 下圖顯示憑證鏈結無效的憑證範例，其中中繼和根憑證不相符：

解析度

取得包含完整有效憑證鏈結的憑證 (如果還沒有的話)。

執行下列 openssl 指令，確認憑證鏈正確無誤且完整：

openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert

將驗證過的憑證鏈結上傳至 KeyStore。

伺服器或用戶端傳送的憑證已過期或不明

如果伺服器/用戶端在北向或南向連線中傳送不正確/過期的憑證，另一端 (伺服器/用戶端) 會拒絕該憑證，導致 TLS/SSL 交握失敗。

診斷

判斷錯誤是發生在北向或南向連線。如需進一步瞭解如何判斷問題來源，請參閱「判斷問題來源」。
執行 tcpdump 公用程式，收集更多資訊：
- 如果您是私有雲使用者，可以在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (適用於連入或北向連線)，也可以是訊息處理器 (適用於連出或南向連線)。根據步驟 1 的判斷結果，伺服器可以是邊緣路由器 (適用於連入或北向連線)，也可以是後端伺服器 (適用於連出或南向連線)。
- 如果您是公有雲使用者，則只能在用戶端應用程式 (適用於連入或北向連線) 或後端伺服器 (適用於連出或南向連線) 收集 tcpdump 資料，因為您無法存取 Edge 路由器或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
如要進一步瞭解如何使用 tcpdump 指令，請參閱 tcpdump 資料。
使用 Wireshark 或類似工具分析 tcpdump 資料。
從 tcpdump 輸出內容判斷在驗證步驟中拒絕憑證的主機 (用戶端或伺服器)。
如果資料未加密，您可以從 tcpdump 輸出內容中擷取另一端傳送的憑證。這項資訊有助於比較這個憑證與信任儲存區中的憑證是否相符。
請參閱tcpdump範例，瞭解訊息處理器與後端伺服器之間的 SSL 通訊。
範例 tcpdump 顯示「憑證不明」錯誤
1. 訊息處理器 (用戶端) 會在訊息 #59 中，將「Client Hello」傳送至後端伺服器 (伺服器)。
2. 後端伺服器會在訊息 #61 中，將「Server Hello」傳送至訊息處理器。
3. 雙方會相互驗證所用的通訊協定和加密套件演算法。
4. 後端伺服器會將憑證和「Server Hello Done」訊息傳送至訊息處理器 (訊息 #68)。
5. 訊息處理器會在訊息 #70 中傳送嚴重警示「Description: Certificate Unknown」(說明：憑證不明)。
6. 進一步查看訊息 #70，除了下方顯示的快訊訊息外，沒有其他詳細資料：
7. 查看訊息 #68，瞭解後端伺服器傳送的憑證詳細資料，如下圖所示：
8. 如上圖所示，後端伺服器的憑證和完整鏈結都位於「憑證」部分下方。
如果路由器 (北向) 或訊息處理器 (南向) 發現憑證不明，如上例所示，請按照下列步驟操作：
1. 取得儲存在特定信任儲存區的憑證及其鏈結。(請參閱路由器虛擬主機設定和訊息處理器目標端點設定)。您可以使用下列 API 取得憑證詳細資料：
  1. 在信任儲存區中取得憑證名稱：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs
```
  2. 取得信任儲存區中憑證的詳細資料：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/truststore-name/certs/cert-name
```
2. 檢查儲存在路由器 (北向) 或訊息處理器 (南向) 信任儲存區中的憑證，是否與儲存在用戶端應用程式 (北向) 或目標伺服器 (南向) 金鑰儲存區中的憑證相符，或是與從 tcpdump 輸出內容取得的憑證相符。如果不一致，就是造成 TLS/SSL 握手失敗的原因。
如果用戶端應用程式 (北向) 或目標伺服器 (南向) 發現憑證不明，請按照下列步驟操作：
1. 取得特定 KeyStore 中儲存的憑證所用完整憑證鏈結。(請參閱 Router 的虛擬主機設定，以及訊息處理器的目標端點設定)。您可以使用下列 API 取得憑證詳細資料：
  1. 在金鑰儲存庫中取得憑證名稱：
```
curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  2. 取得 KeyStore 中憑證的詳細資料：
```
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 儲存在路由器金鑰儲存區的憑證已過期。儲存在用戶端應用程式金鑰儲存區的憑證已過期 (雙向 SSL)。	將新憑證及其完整鏈結上傳至適當主機上的 KeyStore。
憑證已過期	SouthBound 儲存在目標伺服器金鑰儲存區的憑證已過期。儲存在訊息處理器金鑰儲存區的憑證已過期 (雙向 SSL)。	將新憑證及其完整鏈結上傳至適當主機上的 KeyStore。
不明憑證	NorthBound 用戶端應用程式信任存放區中儲存的憑證與 Router 的憑證不符。路由器信任儲存區中儲存的憑證與用戶端應用程式的憑證不符 (雙向 SSL)。	將有效憑證上傳至適當主機上的信任儲存區。
不明憑證	SouthBound 儲存在目標伺服器信任儲存庫的憑證與 Message Processor 的憑證不符。儲存在 Message Processor 信任儲存區的憑證與目標伺服器的憑證不符 (雙向 SSL)。	將有效憑證上傳至適當主機上的信任儲存區。

已啟用 SNI 伺服器

如果用戶端與啟用伺服器名稱指示 (SNI) 的伺服器通訊，但用戶端未啟用 SNI，就可能發生 TLS/SSL 握手失敗的情況。這可能發生在 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 和步驟 2 取得的憑證不同，表示指定的伺服器已啟用 SNI。

確認伺服器已啟用 SNI 後，請按照下列步驟操作，檢查 TLS/SSL 交握失敗是否是因為用戶端無法與 SNI 伺服器通訊所致。

診斷

判斷錯誤是發生在北向或南向連線。如需進一步瞭解如何判斷問題來源，請參閱「判斷問題來源」。
執行 tcpdump 公用程式，收集更多資訊：
- 如果您是私有雲使用者，可以在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (適用於連入或北向連線)，也可以是訊息處理器 (適用於連出或南向連線)。根據步驟 1 的判斷結果，伺服器可以是邊緣路由器 (適用於連入或北向連線)，也可以是後端伺服器 (適用於連出或南向連線)。
- 如果您是公有雲使用者，則只能在用戶端應用程式 (適用於連入或北向連線) 或後端伺服器 (適用於連出或南向連線) 收集 tcpdump 資料，因為您無法存取 Edge 路由器或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
如要進一步瞭解如何使用 tcpdump 指令，請參閱 tcpdump 資料。
使用 Wireshark 或類似工具分析 tcpdump 輸出內容。
以下是使用 Wireshark 分析 tcpdump 的範例：
1. 在本例中，Edge 訊息處理器與後端伺服器 (南向連線) 之間發生 TLS/SSL 交握失敗。
2. 下方 tcpdump 輸出內容中的訊息 #4 顯示，訊息處理器 (來源) 已將「Client Hello」訊息傳送至後端伺服器 (目的地)。
3. 選取「Client Hello」訊息，即可查看訊息處理器使用的 TLSv1.2 通訊協定。
4. 訊息 #4 顯示後端伺服器確認來自訊息處理器的「Client Hello」訊息。
5. 後端伺服器會立即傳送「Fatal Alert : Handshake Failure」給訊息處理器 (訊息 #5)。這表示 TLS/SSL 交握失敗，連線將會關閉。
6. 查看訊息 #6，瞭解下列資訊：
  - 後端伺服器支援 TLSv1.2 通訊協定。這表示訊息處理器和後端伺服器之間的通訊協定相符。
  - 不過，後端伺服器仍會將「Fatal Alert: Handshake Failure」傳送至訊息處理器，如下圖所示：
7. 發生這項錯誤的原因如下：
  - 訊息處理器未採用後端伺服器支援的加密套件演算法。
  - 後端伺服器已啟用 SNI，但用戶端應用程式未傳送伺服器名稱。
8. 請詳閱 tcpdump 輸出內容中的訊息 #3 (Client Hello)。請注意，如下所示，缺少「Extension: server_name」：
9. 這可確認訊息處理器未將 server_name 傳送至啟用 SNI 的後端伺服器。
10. 這就是 TLS/SSL 握手失敗的原因，也是後端伺服器將「Fatal Alert: Handshake Failure」傳送至 Message Processor 的原因。
確認訊息處理器上的 jsse.enableSNIExtension property system.properties 已設為 false，確認訊息處理器未啟用與啟用 SNI 的伺服器通訊。

解析度

請按照下列步驟操作，讓訊息處理器與啟用 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 輸出內容。