本頁面由 Cloud Translation API 翻譯而成。

TLS/SSL 握手失敗

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。資訊

問題

如果用戶端和伺服器無法使用傳輸層安全標準 (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 握手失敗輸出至傳入 (北入) 或傳出 (南向) 連線。其他參考資訊瞭解北向與南向的連線。

診斷

判斷錯誤是發生在北距或 southbound 連線。如要進一步瞭解這項功能確定，請參閱判斷問題來源。
執行 tcpdump 公用程式來收集進一步資訊：
- 如果您是 Private Cloud 使用者，可以收集 tcpdump 要求存取資料用戶端可以是用戶端應用程式 (對於傳入、或北極連線) 或訊息處理器 (用於連出或南向連線)。伺服器可以是 Edge Router 傳入或北向連線) 或後端伺服器。
- 如果您是公有雲使用者，可以收集 tcpdump 僅限用戶端應用程式 (傳入或北向連線) 的資料或後端伺服器的資料 (針對連出或南向連線)，因為您需要無法存取 Edge Router 或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
敬上請參閱 tcpdump 資料，進一步瞭解如何使用 tcpdump 指令
使用 Wireshark 工具分析 tcpdump 資料或類似工具
對於 tcpdump 會使用 Wireshark：
- 在此範例中，訊息處理器與與後端伺服器 (連出或南向連線) 通訊。
- 以下 tcpdump 輸出內容中的訊息 #4 顯示訊息處理器 (來源) 傳送了「客戶您好」訊息傳送至後端伺服器 (目的地)
- 如果選取 Client Hello 訊息，系統會顯示訊息處理器正在使用 TLSv1.2 通訊協定，如下所示：
- 訊息 #5 顯示後端伺服器確認「Client Hello」訊息訊息處理器
- 後端伺服器會立即將 Fatal Alert : Close Notify 傳送至 Message Processor (訊息 #6)。這表示 TLS/SSL 握手失敗，並且設為關閉
- 深入瞭解郵件 #6 顯示，造成 TLS/SSL 握手失敗的原因後端伺服器僅支援 TLSv1.0 通訊協定，如下所示：
- 因為訊息處理者使用的通訊協定與後端伺服器，後端伺服器傳送了下列訊息：Fatal Alert Message: Close 通知。

解析度

Message Processor 預設在 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. 假如您設定了目標伺服器，然後使用這個 management API 會在目標伺服器設定

密碼不符

如果用戶端使用的加密套件演算法並未運作，就會顯示 TLS/SSL 握手失敗。在 Apigee Edge 的傳入 (北入) 或傳出 (南向) 連線中支援。另請參閱瞭解北向與南向的連線。

診斷

判斷錯誤是否發生於 northbound 或 southbound 連線。如需關於如何判斷的詳細說明，請參閱決策中問題來源
執行 tcpdump 公用程式來收集進一步資訊：
- 如果您是 Private Cloud 使用者，可以收集 tcpdump 要求存取資料用戶端可以是用戶端應用程式 (對於傳入、或北極連線) 或訊息處理器 (用於連出或南向連線)。伺服器可以是 Edge Router 傳入或北向連線) 或後端伺服器。
- 如果您是公有雲使用者，可以收集 tcpdump 僅限用戶端應用程式 (傳入或北向連線) 的資料或後端伺服器的資料 (針對連出或南向連線)，因為您需要無法存取 Edge Router 或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
敬上請參閱 tcpdump 資料，進一步瞭解如何使用 tcpdump 指令。
使用 Wireshark 工具分析 tcpdump 資料或任何其他慣用的工具
以下是使用 Wireshark 的 tcpdump 輸出內容範例分析：
- 在這個範例中，用戶端應用程式與 Edge 路由器 (北方連線)。已在邊緣收集 tcpdump 輸出內容路由器
- 以下 tcpdump 輸出內容中的訊息 #4 顯示，用戶端應用程式 (來源) 傳送了一張「客戶您好」訊息傳送至 Edge Router (目的地)
- 選取 Client Hello 訊息，代表用戶端應用程式正在使用 TLSv1.2 通訊協定。
- 訊息 #5 顯示邊緣路由器確認「Client Hello」訊息用戶端應用程式
- Edge 路由器會立即傳送嚴重警告：握手失敗 用戶端應用程式 (訊息 #6)。這表示 TLS/SSL 握手失敗，且無法連線即將打烊
- 進一步瞭解訊息 #6 顯示的資訊如下：
  - Edge Router 支援 TLSv1.2 通訊協定。也就是說可在用戶端應用程式與 Edge Router 之間進行
  - 不過，Edge 路由器仍會傳送嚴重警示：握手用戶端應用程式失敗，如以下螢幕截圖所示：
- 這項錯誤可能是由下列其中一個問題造成：
  - 用戶端應用程式未使用 Edge Router。
  - Edge Router 已啟用 SNI，但用戶端應用程式並未傳送伺服器名稱
- tcpdump 輸出內容中的訊息 #4 列出了用戶端支援的加密套件演算法應用程式，如下所示：
- Edge Router 支援的加密套件演算法清單列於 /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 中的憑證有誤，就會發生 TLS/SSL 握手失敗。可在 Apigee Edge 的傳入 (北向) 或傳出 (南向) 連線中傳送。其他參考資訊瞭解北向與南向的連線。

如果問題為「北方」，您可能會看到不同的錯誤訊息視根本原因而定

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

錯誤訊息

視 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 公有雲使用者

主機名稱不相符

診斷

請記下以下 Edge Management API 呼叫傳回網址中使用的主機名稱：
```
curl -v https://myorg.domain.com/v1/getinfo
```
敬上例如：
```
curl -v https://api.enterprise.apigee.com/v1/getinfo
```

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

取得 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

使用 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 Truststores

憑證鏈結不完整或不正確

診斷

取得儲存在特定 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
```
  如果您是公有雲使用者：
```
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
```
  如果您是公有雲使用者：
```
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. 以下圖表顯示含有無效憑證鏈結的範例憑證，中間憑證與根憑證不相符：

解析度

如果您尚未取得憑證，請取得完整且有效的憑證憑證鏈結。
執行下列 opensl 指令，驗證憑證鏈結是否正確並完成：
```
openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
```
將已驗證的憑證鏈結上傳至 KeyStore。

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

如果伺服器/用戶端在北側傳送錯誤/過期的憑證或對點連線，則另一端 (伺服器/用戶端) 會拒絕憑證導致 TLS/SSL 握手失敗。

診斷

判斷錯誤是發生在北距或 southbound 連線。如要進一步瞭解這項功能確定，請參閱判斷問題來源。
執行 tcpdump 公用程式來收集進一步資訊：
- 如果您是 Private Cloud 使用者，可以收集 tcpdump 要求存取資料用戶端可以是用戶端應用程式 (對於傳入、或北極連線) 或訊息處理器 (用於連出或南向連線)。伺服器可以是 Edge Router 傳入或北向連線) 或後端伺服器。
- 如果您是公有雲使用者，可以收集 tcpdump 僅限用戶端應用程式 (傳入或北向連線) 的資料或後端伺服器的資料 (針對連出或南向連線)，因為您需要無法存取 Edge Router 或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
敬上請參閱 tcpdump 資料，進一步瞭解如何使用 tcpdump 指令。
使用 Wireshark 或tcpdump 類似的工具
從 tcpdump 輸出內容中，找出拒絕連線的主機 (用戶端或伺服器) 驗證憑證
您可以擷取另一端傳送的憑證 (前提是 tcpdump 輸出內容為未加密的資料。這有助於比較這個憑證是否與信任存放區中可用的憑證
查看範例 tcpdump，瞭解訊息處理器與後端伺服器
tcpdump 範例顯示憑證不明錯誤
1. 訊息處理器 (用戶端) 傳送「Client Hello」將要求傳送至後端伺服器 (伺服器) 訊息。
2. 後端伺服器傳送「Server Hello」訊息中的訊息處理者 #61.
3. 兩者會共同驗證所使用的通訊協定和加密套件演算法。
4. 後端伺服器將「Certificate」和「Server Hello Done」訊息傳送至訊息 #68 中的「Message Processor」字樣。
5. 訊息處理器傳送嚴重警示「說明：憑證」訊息 #70 中的「不明」。
6. 深入瞭解訊息 #70，沒有其他詳情而不是快訊訊息，如下所示：
7. 查看訊息 #68，取得後端傳送的憑證相關詳細資料，如下圖所示：
8. 可取得後端伺服器的憑證及其完整鏈結「憑證」下方部分，如上圖所示。
如果路由器 (北方) 發現憑證不明，訊息處理器 (southbound) (如上述範例所示)，然後依循這些步驟：
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. 檢查路由器信任儲存庫中儲存的憑證 (北向) 或訊息處理器 (southbound) 與儲存在用戶端應用程式的 KeyStore (北入) 或目標伺服器 (南界)，或是會從 tcpdump 輸出內容取得。所以造成差異導致 TLS/SSL 握手失敗
如果用戶端應用程式發現不明憑證 (北界) 或目標伺服器 (southbound)，請按照下列步驟操作：
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 中儲存的憑證 (北方)，或是 Message Processor (southbound) 符合儲存在用戶端應用程式 (北方) 或目標伺服器 (南方)，或者是從 tcpdump 輸出內容取得。如果兩者不一致，原因就是 SSL 握手失敗
如果伺服器/用戶端傳送的憑證已過期，則接收端用戶端/伺服器拒絕憑證，而您會在 tcpdump:
快訊 (等級：嚴重、說明：憑證已過期)
確認相關主機 KeyStore 中的憑證已過期。

解析度

如要解決上述示例中的問題，請上傳有效的後端伺服器的提供給訊息處理器的信任者憑證

下表摘要說明解決問題的步驟，具體說明問題。

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

SNI 已啟用伺服器

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

首先，您必須找出所用伺服器的主機名稱和通訊埠號碼，然後檢查啟用或未啟用 SNI

識別已啟用 SNI 的伺服器

執行 openssl 指令，並嘗試連線至相關的伺服器主機名稱 (Edge) 路由器或後端伺服器)，「不傳遞伺服器名稱」，如下所示：
```
openssl s_client -connect hostname:port
```
敬上你可能會取得憑證，有時可能會發現 opensl 指令，如下所示：
```
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 指令，並嘗試連線至相關伺服器主機名稱 (Edge 路由器或後端伺服器)，如下所示傳遞伺服器名稱：
```
openssl s_client -connect hostname:port -servername hostname
```
如果步驟 1 發生握手失敗，或是在步驟 1 中取得不同的憑證步驟 2，表示指定伺服器已啟用 SNI。

確認伺服器已啟用 SNI 後，請按照下列步驟檢查是否因用戶端無法與 SNI 伺服器

診斷

判斷錯誤是發生在北距或 southbound 連線。如要進一步瞭解這項功能確定，請參閱判斷問題來源。
執行 tcpdump 公用程式來收集進一步資訊：
- 如果您是 Private Cloud 使用者，可以收集 tcpdump 要求存取資料用戶端可以是用戶端應用程式 (對於傳入、或北極連線) 或訊息處理器 (用於連出或南向連線)。伺服器可以是 Edge Router 傳入或北向連線) 或後端伺服器。
- 如果您是公有雲使用者，可以收集 tcpdump 僅限用戶端應用程式 (傳入或北向連線) 的資料或後端伺服器的資料 (針對連出或南向連線)，因為您需要無法存取 Edge Router 或訊息處理器。
```
tcpdump -i any -s 0 host IP address -w File name
```
敬上詳情請見 tcpdump 資料，進一步瞭解如何使用 tcpdump 指令。
使用 Wireshark 或tcpdump 類似的工具
以下是使用 Wireshark 的 tcpdump 分析範例：
1. 在此範例中，邊緣訊息之間發生 TLS/SSL 握手失敗處理器和後端伺服器 (南界連線)。
2. 以下 tcpdump 輸出內容中的訊息 #4 顯示訊息處理器 (來源) 已傳送「客戶您好」訊息傳送至後端伺服器 (目的地)。
3. 選取「Client Hello」訊息會顯示處理器使用 TLSv1.2 通訊協定。
4. 訊息 #4 顯示後端伺服器確認「Client Hello」訊息來自訊息處理器
5. 後端伺服器會立即傳送「嚴重快訊：握手」 「訊息處理者」失敗 (訊息 #5)。這表示 TLS/SSL 握手並關閉連線。
6. 閱讀訊息 6 以瞭解下列資訊
  - 後端伺服器支援 TLSv1.2 通訊協定。也就是說在訊息處理器與後端伺服器之間進行比對
  - 不過，後端伺服器仍會傳送「嚴重快訊：握手」 「訊息處理器」失敗，如下圖所示：
7. 這個錯誤的可能原因如下：
  - 訊息處理器並未使用後端伺服器
  - 後端伺服器已啟用 SNI，但用戶端應用程式未傳送伺服器名稱
8. 進一步查看 tcpdump 輸出內容中的訊息 #3 (Client Hello)。請注意，缺少 Extension: 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

擁有這個檔案的擁有者 (apigee:apigee)：

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

重新啟動訊息處理器。

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

如果您有多個訊息處理器，請在所有訊息處理器。

如果您無法判斷 TLS/SSL 握手失敗的原因並修正問題；如需進一步協助，請與 Apigee Edge 支援。請提供問題的完整詳細資料以及 tcpdump 輸出內容。

TLS/SSL 握手失敗

問題

錯誤訊息

可能原因

通訊協定 不相符

診斷

解析度

密碼不符

診斷

解析度

憑證不正確

錯誤訊息

可能原因

主機名稱 不相符

診斷

解析度

參考資料

憑證鏈結不完整或不正確

診斷

解析度

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

診斷

解析度

SNI 已啟用 伺服器

識別已啟用 SNI 的伺服器

診斷

解析度

通訊協定不相符

主機名稱不相符

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

SNI 已啟用伺服器