TLS/SSL 握手失敗

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

問題

用戶端和伺服器無法使用 TLS/SSL 通訊協定建立通訊時，會發生 TLS/SSL 握手失敗。當 Apigee Edge 中發生這個錯誤時，用戶端應用程式會收到 HTTP 狀態 503 和 Service Unavailable 訊息。您會在發生 TLS/SSL 握手失敗的 API 呼叫後看到這個錯誤。

錯誤訊息

HTTP/1.1 503 Service Unavailable

當 TLS/SSL 握手失敗時，您也可以看到以下錯誤訊息：

Received fatal alert: handshake_failure

可能原因

TLS (傳輸層安全標準 (TLS) 是先前採用 SSL) 的標準安全技術，會在網路伺服器與網路用戶端 (例如瀏覽器或應用程式) 之間建立加密連結。「握手」程序可讓 TLS/SSL 用戶端和伺服器建立一組密鑰，以便與這些用戶端進行通訊。在這個過程中，用戶端和伺服器會：

1. 同意使用何種通訊協定版本。
2. 選取要使用的加密編譯演算法。
3. 交換及驗證數位憑證，互相驗證。

如果 TLS/SSL 握手成功，TLS/SSL 用戶端和伺服器之間會互相安全地傳輸資料。否則，如果傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 握手失敗，導致連線終止，且用戶端收到 503 Service Unavailable 錯誤，

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

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

通訊協定不符

如果用戶端在傳入 (北行) 或傳出 (南行) 連線時，伺服器不支援用戶端使用的通訊協定，就會發生傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 握手失敗。另請參閱「 瞭解北邊界和向南連接」。

診斷

1. 判斷錯誤是在 Northbound 或 southbound 連線上發生。如需做出判斷的進一步指引，請參閱「 判斷問題來源」一文。
2. 執行 tcpdump 公用程式來收集其他資訊：
   • 如果您是 Private Cloud 使用者，便可在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (用於傳入或向北連線) 或訊息處理器 (適用於傳出或南方連線)。根據您在步驟 1 中所做的決定，伺服器可以是 Edge Router (用於傳入或北行連線) 或後端伺服器 (傳出或向南連線連線)。
   • 如果您是公開雲端使用者，由於您無法存取邊緣路由器或訊息處理器，因此只能收集用戶端應用程式 (用於傳入或向北連線) 或後端伺服器 (針對傳出或向外連線) 上的 tcpdump 資料。

   tcpdump -i any -s 0 host IP address -w File name
   

   如要進一步瞭解使用 tcpdump 指令，請參閱 tcpdump 資料。
3. 使用 Wireshark 工具或類似工具分析 tcpdump 資料。
4. 以下是使用 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 Notifications。

解析度

「訊息處理器」會在 Java 8 上執行，預設使用 TLSv1.2 通訊協定。如果後端伺服器不支援 TLSv1.2 通訊協定，您可以採取下列其中一種做法來解決這個問題：

1. 請升級後端伺服器，以支援 TLSv1.2 通訊協定。此為建議的解決方案，因為通訊協定 TLSv1.2 更加安全。
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 設定了 目標伺服器，請使用 這個 Management API，在特定目標伺服器設定中將通訊協定設為 TLSv1.0。

加密配對

如果用戶端在 Apigee Edge 中傳入 (北行) 或傳出 (南端) 連線時伺服器不支援用戶端使用的加密套件演算法，您可能會看到 TLS/SSL 握手失敗。另請參閱「 瞭解北極連線和南極連線」一文。

診斷

1. 判斷錯誤是在 Northbound 或 southbound 連線上發生。如要進一步瞭解如何做出判斷，請參閱「判斷問題來源」一文。
2. 執行 tcpdump 公用程式來收集其他資訊：
   • 如果您是 Private Cloud 使用者，便可在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (用於傳入或向北連線) 或訊息處理器 (適用於傳出或南方連線)。根據您在步驟 1 中所做的決定，伺服器可以是 Edge Router (用於傳入或北行連線) 或後端伺服器 (傳出或向南連線連線)。
   • 如果您是公開雲端使用者，由於您無法存取邊緣路由器或訊息處理器，因此只能收集用戶端應用程式 (用於傳入或向北連線) 或後端伺服器 (針對傳出或向外連線) 上的 tcpdump 資料。

   tcpdump -i any -s 0 host IP address -w File name
   

   如要進一步瞭解使用 tcpdump 指令，請參閱 tcpdump 資料。
3. 您可以使用 Wireshark 工具或任何其他您熟悉的工具分析 tcpdump 資料。
4. 以下是使用 Wireshark 進行 tcpdump 輸出內容的範例分析：
   • 在此範例中，用戶端應用程式和邊緣路由器 (北向連線) 之間發生 TLS/SSL 握手失敗問題。tcpdump 輸出內容收集在 Edge 路由器上。

   • 下方 tcpdump 輸出內容中的訊息 #4 顯示用戶端應用程式 (來源) 將「Client Hello」訊息傳送至 Edge Router (目的地)。

     

   • 選取 Client Hello 訊息，顯示用戶端應用程式正在使用 TLSv1.2 通訊協定。

     

   • 訊息 #5 顯示 Edge Router 確認來自用戶端應用程式的「Client Hello」訊息。
   • Edge Router 會立即將「嚴重快訊：握手失敗」傳送至用戶端應用程式 (訊息 #6)。這代表 TLS/SSL 握手失敗，因此連線即將關閉。
   • 進一步查看訊息 #6 會顯示以下資訊：
     • Edge Router 支援 TLSv1.2 通訊協定。這表示用戶端應用程式與 Edge Router 之間的通訊協定相符。

     • 不過，邊緣路由器仍會將「Fatal Alert: Handshake Failure」傳送至用戶端應用程式，如以下螢幕截圖所示：

       

   • 這項錯誤可能是下列其中一項問題所導致：
     • 用戶端應用程式未使用 Edge Router 支援的加密套件演算法。
     • 邊緣路由器已啟用 SNI，但用戶端應用程式無法傳送伺服器名稱。
   • tcpdump 輸出內容中的訊息 #4 會列出用戶端應用程式支援的加密套件演算法，如下所示：

     

   • /opt/nginx/conf.d/0-default.conf 檔案會列出 Edge Router 支援的加密套件演算法。在此範例中，邊緣路由器僅支援高加密加密套件演算法。
   • 用戶端應用程式不使用任何高加密加密套件演算法，這種不相符的原因是傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 握手失敗。
   • 由於 Edge Router 已啟用 SNI，請向下捲動至 tcpdump 輸出內容中的訊息 #4，確認用戶端應用程式是否正確傳送伺服器名稱，如下圖所示：
     
     
     
   • 如果這個名稱有效，您可以推論出傳輸層安全標準 (TLS)/安全資料傳輸層 (SSL) 握手失敗，因為邊緣路由器不支援用戶端應用程式使用的加密套件演算法。

解析度

您必須確保用戶端使用伺服器支援的加密套件演算法。如要解決前面「診斷」一節所述的問題，請下載並安裝 Java Cryptography Extension (JCE) 套件並在 Java 安裝中加入這個套件，以便支援高加密加密套件演算法。

憑證不正確

如果在 KeyStore/truststore 中的憑證有誤，無論是在 Apigee Edge 傳入 (北行) 或傳出 (南行) 連線，就會發生 TLS/SSL 握手失敗。另請參閱「 瞭解北極連線和向南連接」一文。

如果問題為 Northbound，系統可能會根據根本原因顯示不同的錯誤訊息。

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

錯誤訊息

視 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

可能原因

這個問題的常見原因如下：

原因	說明	誰可以執行疑難排解步驟
主機名稱不符	網址中使用的主機名稱與路由器 KeyStore 中的憑證不符。舉例來說，如果網址使用的主機名稱為 myorg.domain.com，而憑證在 CN 中的主機名稱為 CN=something.domain.com.，就會發生資料不符的問題	邊緣私有雲和公有雲使用者
憑證鏈結不完整或不正確	憑證鏈結不完整或不正確。	僅限邊緣私有雲和公有雲使用者
伺服器或用戶端傳送的憑證已過期或不明	伺服器或用戶端在北邊界或向南連接時，傳送過期或未知的憑證。	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. 取得在特定 KeyStore 中儲存的憑證中使用的 CN。您可以使用下列 Edge Management API 取得憑證的詳細資料：
   1. 從 KeyStore 取得憑證名稱：
      
      如果您是 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. 使用 Edge Management 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。

參考資料

Keystore 和 Truststore

憑證鏈結不完整或有誤

診斷

1. 取得在特定 KeyStore 中儲存的憑證中使用的 CN。您可以使用下列 Edge Management API 取得憑證的詳細資料：
   1. 從 KeyStore 取得憑證名稱：
      
      如果您是 Private Cloud 使用者：
      

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

      如果您是公用 Cloud 使用者：
      

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

   2. 取得 KeyStore 中的憑證詳細資料：
      
      如果您是 Private Cloud 使用者：
      

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

      如果您是公用 Cloud 使用者：
      

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

   3. 驗證憑證及其鏈結，並確認其遵循「 憑證鏈結運作方式」一文中提供的準則，確保憑證是有效且完整的憑證鏈結。如果儲存在 KeyStore 中的憑證鏈不完整或無效，您會看到 TLS/SSL 握手失敗。
   4. 以下摘要顯示含有無效憑證鏈結的憑證範例，其中中繼和根憑證不符：

   核發機構和主體不符的中繼與根憑證範例

   
   

解析度

1. 取得包含完整且有效憑證鏈結的憑證 (如果您尚未取得)。
2. 執行下列 openssl 指令，確認憑證鏈結正確無誤且已完成：

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

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

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

如果伺服器/用戶端在北邊界或向南連線時傳送錯誤/過期的憑證，則其他端 (伺服器/用戶端) 會拒絕導致 TLS/SSL 握手失敗的憑證。

診斷

1. 判斷錯誤是在 Northbound 或 southbound 連線上發生。如需做出判斷的進一步指引，請參閱「 判斷問題來源」一文。
2. 執行 tcpdump 公用程式來收集其他資訊：
   • 如果您是 Private Cloud 使用者，便可在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (用於傳入或向北連線) 或訊息處理器 (適用於傳出或南方連線)。根據您在步驟 1 中所做的決定，伺服器可以是 Edge Router (用於傳入或北行連線) 或後端伺服器 (傳出或向南連線連線)。
   • 如果您是公開雲端使用者，由於您無法存取邊緣路由器或訊息處理器，因此只能收集用戶端應用程式 (用於傳入或向北連線) 或後端伺服器 (針對傳出或向外連線) 上的 tcpdump 資料。

   tcpdump -i any -s 0 host IP address -w File name
   

   如要進一步瞭解使用 tcpdump 指令，請參閱 tcpdump 資料。
3. 使用 Wireshark 或類似工具分析 tcpdump 資料。
4. 從 tcpdump 輸出內容中，找出在驗證步驟期間拒絕憑證的主機 (用戶端或伺服器)。
5. 如果資料未加密，您可以從 tcpdump 輸出內容擷取另一端傳送的憑證。這有助於比較這個憑證是否與信任儲存庫中的可用憑證相符。
6. 查看 tcpdump 範例，瞭解訊息處理器和後端伺服器之間的安全資料傳輸層 (SSL) 通訊。

   顯示不明憑證錯誤的範例 tcpdump

   
   

   1. 訊息處理器 (用戶端) 會在訊息 #59 中將「Client Hello」傳送至後端伺服器 (伺服器)。
   2. 後端伺服器將「Server Hello」傳送至訊息 #61 中的訊息處理器。
   3. 兩者都會驗證所使用的通訊協定和加密套件演算法。
   4. 後端伺服器會將憑證和 Server Hello Done 訊息傳送至訊息 #68 中的訊息處理器。
   5. 訊息處理者傳送訊息 #70 中的嚴重警示 "Description: Certificate Unknown"。
   6. 深入瞭解訊息 #70，除了快訊訊息之外，沒有其他詳細資料，如下所示：

      
      

   7. 查看訊息 #68，取得後端伺服器傳送的憑證詳細資料，如下圖所示：

      

   8. 後端伺服器的憑證及其完整鏈結都會顯示在「憑證」區段下方，如上圖所示。
7. 如果路由器 (北行) 或訊息處理器 (南行) 發現憑證不明 (如上圖所示)，請按照下列步驟操作：
   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. 檢查儲存在路由器信任儲存庫 (北界) 或訊息處理器 (南行) 中的憑證，是否與儲存在用戶端應用程式 KeyStore (北行) 或目標伺服器 (南行) 中的憑證相符，或是從 tcpdump 輸出內容取得的憑證。如果出現不相符的情形，表示 TLS/SSL 握手失敗的原因。
8. 如果用戶端應用程式 (Northbound) 或目標伺服器 (南行) 發現憑證不明，請按照下列步驟操作：
   1. 取得儲存在特定 KeyStore 中憑證的完整憑證鏈結。(請參閱路由器的虛擬主機設定和訊息處理器的目標端點設定)。您可以使用下列 API 取得憑證的詳細資料：
      1. 在 KeyStore 中取得憑證名稱：

         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. 檢查儲存在路由器 KeyStore (北方) 或訊息處理器 (南行) 中的憑證，是否與用戶端應用程式信任儲存庫 (北行) 或目標伺服器 (南行) 中儲存的憑證相符，或是從 tcpdump 輸出內容取得的憑證。如果出現不相符的情形，則表示 SSL 握手失敗的原因。
9. 如果伺服器/用戶端傳送的憑證已過期，接收的用戶端/伺服器會拒絕憑證，而 tcpdump 中會顯示以下警示訊息：

   快訊 (等級：嚴重、說明：憑證已過期)

10. 驗證相關主機 KeyStore 中的憑證已過期。

解析度

如要解決上述範例發現的問題，請將有效的後端伺服器憑證上傳到訊息處理器的信任者。

下表根據問題原因摘要列出解決步驟。

原因	說明	解析度
憑證過期	NorthBound 儲存在路由器 KeyStore 中的憑證已過期。 儲存在用戶端應用程式 KeyStore 中的憑證已過期 (雙向 SSL)。	將新憑證及其完整鏈結上傳至適當主機的 KeyStore。
	SouthBound 儲存在目標伺服器 KeyStore 的憑證已過期， 儲存在訊息處理器金鑰庫中的憑證已過期 (雙向 SSL)。	將新憑證及其完整鏈結上傳至適當主機的 KeyStore。
不明的憑證	NorthBound 儲存在用戶端應用程式信任儲存庫中的憑證與路由器的憑證不相符。 儲存在路由器信任存放區中的憑證與用戶端應用程式憑證 (雙向安全資料傳輸層 (SSL)) 不符。	將有效憑證上傳至適當主機的信任儲存庫。
	SouthBound 儲存在目標伺服器信任儲存庫中的憑證與訊息處理器的憑證不相符。 儲存在訊息處理器信任存放區中的憑證與目標伺服器的憑證 (雙向安全資料傳輸層) 不符。	將有效憑證上傳至適當主機的信任儲存庫。

啟用 SNI 的伺服器

當用戶端與已啟用伺服器名稱指示 (SNI) 的伺服器通訊，但用戶端未啟用 SNI 時，可能會發生 TLS/SSL 握手失敗。這可能是在邊緣，或邊緣中的南行連線。

首先，您需要識別所用伺服器的主機名稱和通訊埠號碼，並檢查其是否已啟用 SNI。

已啟用 SNI 的伺服器識別

1. 執行 openssl 指令，並嘗試在未傳遞伺服器名稱的情況下連線至相關伺服器主機名稱 (邊緣路由器或後端伺服器)，如下所示：

   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 和步驟 #2 中取得其他憑證，就表示指定的伺服器已啟用 SNI。

確認伺服器已啟用 SNI 後，請按照下列步驟，確認用戶端無法與 SNI 伺服器通訊而導致 TLS/SSL 握手失敗原因。

診斷

1. 判斷錯誤是在 Northbound 或 southbound 連線上發生。如需做出判斷的進一步指引，請參閱「 判斷問題來源」一文。
2. 執行 tcpdump 公用程式來收集其他資訊：
   • 如果您是 Private Cloud 使用者，便可在相關用戶端或伺服器收集 tcpdump 資料。用戶端可以是用戶端應用程式 (用於傳入或向北連線) 或訊息處理器 (適用於傳出或南方連線)。根據您在步驟 1 中所做的決定，伺服器可以是 Edge Router (用於傳入或北行連線) 或後端伺服器 (傳出或向南連線連線)。
   • 如果您是公開雲端使用者，由於您無法存取邊緣路由器或訊息處理器，因此只能收集用戶端應用程式 (用於傳入或向北連線) 或後端伺服器 (針對傳出或向外連線) 上的 tcpdump 資料。

   tcpdump -i any -s 0 host IP address -w File name
   

   如要進一步瞭解使用 tcpdump 指令，請參閱 tcpdump 資料。
3. 使用 Wireshark 或類似工具分析 tcpdump 輸出內容。
4. 以下是使用 Wireshark 進行 tcpdump 分析的範例：
   1. 在此範例中，邊緣訊息處理器與後端伺服器 (南接連線) 之間發生 TLS/SSL 握手失敗。
   2. 下方 tcpdump 輸出內容中的訊息 #4 顯示訊息處理器 (來源) 將「Client Hello」訊息傳送至後端伺服器 (目的地)。

      

   3. 選取「Client Hello」訊息，「訊息處理器」使用的是 TLSv1.2 通訊協定。

      

   4. 訊息 #4 顯示後端伺服器會確認訊息處理器的「Client Hello」訊息。
   5. 後端伺服器會立即將「嚴重快訊：握手失敗」傳送至訊息處理器 (訊息 #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 握手失敗的原因，以及後端伺服器傳送「嚴重快訊：握手失敗」至訊息處理器的原因。
5. 確認訊息處理器的 system.properties 中的 jsse.enableSNIExtension property 已設為 false，藉此確認訊息處理器並未啟用與支援 SNI 的伺服器通訊。

解析度

請執行下列步驟，讓訊息處理器與啟用 SNI 的伺服器通訊：

1. 建立 /opt/apigee/customer/application/message-processor.properties 檔案 (如果尚未建立的話)。
2. 在這個檔案中新增下列程式碼：conf_system_jsse.enableSNIExtension=true
3. 將這個檔案的擁有者設為「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 輸出內容。