TLS/SSL handshake の失敗

症状

クライアントとサーバーが TLS/SSL プロトコルを使用して接続を確立できない場合、TLS/SSL handshake の失敗が発生します。Apigee Edge でこのエラーが発生すると、クライアントアプリケーションは、「Service Unavailable」というメッセージとともに HTTP ステータス 503 を受け取ります。API 呼び出しで TLS/SSL handshake の失敗が発生すると、このエラーが表示されます。

エラーメッセージ

    HTTP/1.1 503 Service Unavailable

加えて、TLS/SSL handshake の失敗が発生すると、次のエラーメッセージが表示されることもあります。

    Received fatal alert: handshake_failure

考えられる原因

TLS（Transport Layer Security: SSL の後継）は、ウェブサーバーとウェブクライアント（ブラウザやアプリなど）の間で暗号化されたリンクを確立するための標準的なセキュリティテクノロジーです。handshake というプロセスにより、TLS/SSL クライアントとサーバーが通信で使用できる秘密鍵が確立します。このプロセスが行われる間、クライアントとサーバーでは以下が実行されます。

使用するプロトコルのバージョンについて合意します。
使用する暗号化アルゴリズムを選択します。
デジタル証明書を交換して検証することにより、相互に認証します。

TLS/SSL handshake が成功すると、TLS/SSL クライアントとサーバーはデータを相互に安全に転送します。TLS/SSL handshake が失敗した場合は、接続が終了し、クライアントは 503 Service Unavailable エラーを受け取ります。

TLS/SSL handshake が失敗する原因として以下が考えられます。

原因	説明	トラブルシューティング手順を実施できるユーザー
プロトコルの不一致	クライアントによって使用されるプロトコルが、サーバーでサポートされていません。	Private Cloud および Public Cloud のユーザー
暗号スイートの不一致	クライアントによって使用される暗号スイートが、サーバーでサポートされていません。	Private Cloud および Public Cloud のユーザー
正しくない証明書	クライアントによって使用される URL のホスト名が、サーバー側で格納されている証明書のホスト名と一致しません。	Private Cloud および Public Cloud のユーザー
	クライアント側またはサーバー側に格納されている証明書チェーンが不完全であるか、無効です。	Private Cloud および Public Cloud のユーザー
	クライアントからサーバーまたはサーバーからクライアントに送信された証明書が正しくないか、期限切れです。	Private Cloud および Public Cloud のユーザー
SNI が有効になっているサーバー	バックエンドサーバーで Server Name Indication（SNI）が有効になっていますが、クライアントが SNI サーバーと通信できません。	Private Cloud ユーザーのみ

プロトコルの不一致

クライアントで使用されるプロトコルが、サーバーの受信（上り）または送信（下り）のいずれかの接続でサポートされていない場合、TLS/SSL handshake の失敗が発生します。上りと下りの接続についてもご覧ください。

診断

上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
tcpdump ユーティリティを実行し、さらに詳しい情報を収集します。
- Private Cloud ユーザーの場合、該当するクライアントまたはサーバーの tcpdump データを収集できます。クライアントは、クライアントアプリ（受信つまり上り接続の場合）、または Message Processor（送信つまり下り接続の場合）である可能性があります。サーバーは、ステップ 1 の判別に応じて Edge Router（受信つまり上り接続の場合）またはバックエンドサーバー（送信つまり下り接続の場合）です。
- Public Cloud ユーザーの場合、Edge Router や Message Processor にアクセスできないので、クライアントアプリ（受信つまり上り接続）またはバックエンドサーバー（送信つまり下り接続）の tcpdump データのみを収集できます。
```
    tcpdump -i any -s 0 host IP address -w File name
    
```
tcpdump コマンドの使用に関する詳細情報については、tcpdump データをご覧ください。
Wireshark ツールまたは同様のツールを使用して tcpdump データを分析します。
以下に、Wireshark を使用した場合の tcpdump の分析例を示します。
- この例では、Message Processor とバックエンドサーバー（送信つまり下り接続）の間で TLS/SSL handshake の失敗が発生しました。
- 以下の tcpdump 出力の 4 番目のメッセージには、Message Processor（送信元）が「Client Hello」メッセージをバックエンドサーバー（宛先）に送信したことが示されています。
- Client Hello メッセージを選択すると、次のように、Message Processor が TLSv1.2 プロトコルを使用していることがわかります。
- 5 番目のメッセージには、バックエンドサーバーが Message Processor からの「Client Hello」メッセージを認識したことが示されています。
- バックエンドサーバーは、すぐに「Fatal Alert : Close Notify」を Message Processor に送信します（メッセージ 6）。これは、TLS/SSL handshake が失敗し、接続が閉じられるという意味です。
- 6 番目のメッセージについてさらに詳しく見てみると、TLS/SSL handshake 失敗の原因は、バックエンドサーバーが TLSv1.0 プロトコルのみをサポートしているためです（以下を参照）。
- Message Processor とバックエンドサーバーで使用されているプロトコルが一致しないので、バックエンドサーバーがメッセージ「Fatal Alert Message: Close Notify」を送信しました。

解決策

Message Processor は Java 8 で実行され、デフォルトで TLSv1.2 プロトコルを使用します。バックエンドサーバーが TLSv1.2 プロトコルをサポートしていない場合、この問題を解決するには、以下の手順のいずれかを行います。

TLSv1.2 プロトコルをサポートするように、バックエンドサーバーをアップグレードします。プロトコル TLSv1.2 の安全性は高いので、この解決策をおすすめします。
なんらかの理由でバックエンドサーバーをすぐにアップグレードできない場合は、次の手順に従って、強制的に Message Processor で TLSv1.0 プロトコルを使ってバックエンドサーバーと通信させることができます。
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. プロキシのターゲットサーバーを構成した場合、この管理 API を使用して、特定のターゲットサーバー構成のプロトコルを TLSv1.0 に設定します。

暗号の不一致

クライアントで使用される暗号スイートアルゴリズムがサーバーの受信（上り）または送信（下り）のいずれかの接続でサポートされていない場合、TLS/SSL handshake の失敗が発生します。上りと下りの接続についてもご覧ください。

診断

上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
tcpdump ユーティリティを実行し、さらに詳しい情報を収集します。
- Private Cloud ユーザーの場合、該当するクライアントまたはサーバーの tcpdump データを収集できます。クライアントは、クライアントアプリ（受信つまり上り接続の場合）、または Message Processor（送信つまり下り接続の場合）である可能性があります。サーバーは、ステップ 1 の判別に応じて Edge Router（受信つまり上り接続の場合）またはバックエンドサーバー（送信つまり下り接続の場合）です。
- Public Cloud ユーザーの場合、Edge Router や Message Processor にアクセスできないので、クライアントアプリ（受信つまり上り接続）またはバックエンドサーバー（送信つまり下り接続）の tcpdump データのみを収集できます。
```
    tcpdump -i any -s 0 host IP address -w File name
    
```
tcpdump コマンドの使用に関する詳細情報については、tcpdump データをご覧ください。
Wireshark ツールを使用するか、使い慣れた類似のツールがあればそれを使用して tcpdump データを分析します。
以下に、Wireshark を使った場合の tcpdump 出力の分析例を示します。
- この例では、クライアントアプリケーションと Edge Router（上り接続）の間で、TLS/SSL handshake の失敗が発生しました。tcpdump 出力が Edge ルーターで収集されました。
- 以下の tcpdump 出力の 4 番目のメッセージには、クライアントアプリケーション（送信元）が「Client Hello」メッセージを Edge Router（宛先）に送信したことが示されています。
- 「Client Hello」メッセージを選択すると、クライアントアプリケーションが TLSv1.2 プロトコルを使用していることがわかります。
- 5 番目のメッセージには、Edge Router がクライアントアプリケーションからの「Client Hello」メッセージを認識したことが示されています。
- Edge Router はすぐに「Fatal Alert : Handshake Failure」をクライアントアプリケーションに送信します（メッセージ 6）。これは、TLS/SSL handshake が失敗し、接続が閉じられるという意味です。
- 6 番目のメッセージをさらに詳しく見てみると、以下の情報が示されています。
  - Edge Router は TLSv1.2 プロトコルをサポートしています。つまり、クライアントアプリケーションと Edge Router の間でプロトコルが一致しています。
  - それにもかかわらず、次のスクリーンショットに示すように、Edge Router は「Fatal Alert: Handshake Failure」をクライアントアプリケーションに送信しました。
- このエラーは、以下のいずれかの問題の結果である可能性があります。
  - クライアントアプリケーションが、Edge Router でサポートされる暗号スイートアルゴリズムを使用していない。
  - Edge Router で SNI が有効になっているが、クライアントアプリケーションがサーバー名を送信していない。
- tcpdump 出力の 4 番目のメッセージには、クライアントアプリケーションでサポートされる暗号スイートアルゴリズムが次のようにリストされています。
- Edge Router でサポートされる暗号スイートアルゴリズムは、/opt/nginx/conf.d/0-default.conf ファイルの中にリストされています。この例では、Edge Router が High Encryption 暗号スイートアルゴリズムのみをサポートしています。
- クライアントアプリケーションは、どの High Encryption 暗号スイートアルゴリズムも使用していません。この不一致が TLS/SSL handshake の失敗の原因となっています。
- Edge Router で SNI が有効になっているので、tcpdump 出力のメッセージ 4 を下にスクロールし、クライアントアプリケーションがサーバー名を正しく送信していることを確かめます（以下の図を参照）。
- この名前が有効である場合、TLS/SSL handshake 失敗の原因は、クライアントアプリケーションで使われる暗号スイートアルゴリズムが Edge Router でサポートされていないためだと推測できます。

解決策

サーバーでサポートされる暗号スイートアルゴリズムをクライアントで確実に使用する必要があります。上記の「診断」セクションに記載されている問題を解決するには、Java Cryptography Extension（JCE）パッケージをダウンロードしてインストールし、それを Java インストール環境に組み込むことで、High Encryption 暗号スイートアルゴリズムをサポートします。

正しくない証明書

Apigee Edge の受信（上り）または送信（下り）のいずれかの接続で、正しくない証明書がキーストア / トラストストアに格納されている場合、TLS/SSL handshake の失敗が発生します。上りと下りの接続についてもご覧ください。

上りで問題が発生している場合、原因に応じて異なるエラーメッセージが表示される可能性があります。

以下のセクションでは、エラーメッセージの例と、その問題を診断および解決するための手順を示します。

エラーメッセージ

TLS/SSL handshake の失敗の原因に応じて、異なるエラーメッセージが表示されることがあります。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

考えられる原因

通常、この問題の原因は次のとおりです。

原因	説明	トラブルシューティング手順を実施できるユーザー
ホスト名の不一致	URL で使用されているホスト名と、ルーターのキーストアに格納されている証明書のホスト名が一致しません。たとえば URL で使用されているホスト名が `myorg.domain.com` の場合、証明書のホスト名が CN で `CN=something.domain.com.` と指定されていると、不一致が生じます。	Edge Private および Public Cloud のユーザー
不完全または正しくない証明書チェーン	証明書チェーンが完全ではないか、正しくありません。	Edge Private および Public Cloud のユーザー
クライアントまたはサーバーから送信された証明書が期限切れか、不明です	上りまたは下りの接続で、サーバーまたはクライアントから送信された証明書が期限切れになっているか、不明です。	Edge Private および Public Cloud のユーザー

ホスト名の不一致

診断

次の Edge 管理 API 呼び出しによって返される URL で使われているホスト名を確認します。
```
curl -v https://myorg.domain.com/v1/getinfo
```
例:
```
curl -v https://api.enterprise.apigee.com/v1/getinfo
```

特定のキーストアに格納されている証明書で使われている CN を取得します。次の Edge 管理 API を使用して証明書の詳細を取得できます。

キーストア内の証明書の名前を取得します。

Private Cloud ユーザーの場合、次のように管理 API を使用します。

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

Private Cloud ユーザーの場合、次のように管理 API を使用します。

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

Edge 管理 API を使用してキーストアの証明書の詳細を取得します。

Private Cloud ユーザーの場合:

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

Public Cloud ユーザーの場合:

    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
        },

プライマリ証明書のサブジェクト名に、something.domain.com. という CN が示されています。

API リクエスト URL（上記のステップ 1 を参照）で使用されているホスト名と、証明書のサブジェクト名が一致しないため、TLS/SSL handshake が失敗します。

解決策

この問題は、次の 2 つの方法のいずれかに従って解決できます。

サブジェクト CN がワイルドカード証明書である証明書を取得します（まだ取得していない場合）。その後、新しい完全な証明書チェーンをキーストアにアップロードします。次に例を示します。
```
    "subject": "CN=*.domain.com, OU=Domain Control Validated, O=*.domain.com",
```
既存のサブジェクト CN が設定された、サブジェクト代替名に your-org.your-domain を使用する証明書を取得します（まだ取得していない場合）。その後、完全な証明書チェーンをキーストアにアップロードします。

リファレンス

キーストアとトラストストア

不完全または正しくない証明書チェーン

診断

特定のキーストアに格納されている証明書で使われている CN を取得します。次の Edge 管理 API を使用して証明書の詳細を取得できます。
1. キーストア内の証明書の名前を取得します。
  
  Private Cloud ユーザーの場合:
```
    curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
    
```
  Public Cloud ユーザーの場合:
```
    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
    
```
  Public Cloud ユーザーの場合:
```
    curl -v https://api.enterprise.apigee.com/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    
```
3. 証明書とそのチェーンを調べ、それが「証明書チェーンの仕組み」の記事にあるガイドラインに準拠することを検証して、有効かつ完全なチェーンであることを確かめます。キーストアに格納されている証明書チェーンが完全でないか、無効である場合、TLS/SSL handshake の失敗が表示されます。
4. 以下の図は、中間証明書とルート証明書が一致しない無効な証明書チェーンを含む証明書の例です。

解決策

完全かつ有効な証明書チェーンが含まれる証明書を取得します（まだ取得していない場合）
次の openssl コマンドを実行して、証明書チェーンが正しく完全であることを確認します。
```
    openssl verify -CAfile root-cert -untrusted intermediate-cert main-cert
```
検証済みの証明書チェーンをキーストアにアップロードします。

サーバーまたはクライアントから送信された証明書が期限切れまたは不明

正しくない、または期限切れの証明書が上りまたは下り接続でサーバーまたはクライアントから送信された場合、もう一方の側（サーバーまたはクライアント）はその証明書を拒否し、TLS/SSL handshake が失敗します。

診断

上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
tcpdump ユーティリティを実行し、さらに詳しい情報を収集します。
- Private Cloud ユーザーの場合、該当するクライアントまたはサーバーの tcpdump データを収集できます。クライアントは、クライアントアプリ（受信つまり上り接続の場合）、または Message Processor（送信つまり下り接続の場合）である可能性があります。サーバーは、ステップ 1 の判別に応じて Edge Router（受信つまり上り接続の場合）またはバックエンドサーバー（送信つまり下り接続の場合）です。
- Public Cloud ユーザーの場合、Edge Router や Message Processor にアクセスできないので、クライアントアプリ（受信つまり上り接続）またはバックエンドサーバー（送信つまり下り接続）の tcpdump データのみを収集できます。
```
    tcpdump -i any -s 0 host IP address -w File name
    
```
tcpdump コマンドの使用に関する詳細情報については、tcpdump データをご覧ください。
Wireshark または同様のツールを使用して tcpdump データを分析します。
tcpdump 出力から、検証ステップで証明書を拒否しているホスト（クライアントまたはサーバー）を特定します。
データが暗号化されていなければ、もう一方の側から送信された証明書を tcpdump 出力から取得できます。これは、この証明書と、トラストストアで入手可能な証明書が一致するかどうかを比較するのに役立ちます。
Message Processor とバックエンドサーバーの間の SSL 通信を示す tcpdump の例を確認してください。
「不明な証明書」エラーが表示された tcpdump の例
1. メッセージ 59 によると、Message Processor（クライアント）が「Client Hello」をバックエンドサーバー（サーバー）に送信します。
2. メッセージ 61 によると、バックエンドサーバーは「Server Hello」を Message Processor に送信します。
3. これらは、使用されているプロトコルと暗号スイートアルゴリズムを相互に検証します。
4. メッセージ 68 によると、バックエンドサーバーは証明書と「Server Hello Done」メッセージを Message Processor に送信します。
5. メッセージ 70 によると、Message Processor は致命的なアラート「Description: Certificate Unknown」を送信します。
6. メッセージ 70 をさらに詳しく見ると、下記のように、アラートメッセージ以外の詳細情報はありません。
7. メッセージ 68 を確認し、次の図のような、バックエンドサーバーから送信された証明書に関する詳細を取得します。
8. 上の図のように、バックエンドサーバーの証明書とその完全なチェーンが「Certificates」セクションの下にすべて表示されます。
上記の例のように、Router（上り）または Message Processor（下り）によって証明書が不明だと検出された場合、以下の手順に従います。
1. 特定のトラストストアに格納されている証明書とそのチェーンを取得します（Router の場合は仮想ホスト構成、Message Processor の場合はターゲットエンドポイント構成を参照してください）。次の 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. Router（上り）または Message Processor（下り）に格納されている証明書が、クライアントアプリケーション（上り）またはターゲットサーバー（下り）のキーストアに格納されている証明書、あるいは tcpdump 出力から取得される証明書と一致しているかどうかを確認します。不一致があると、それが TLS/SSL handshake の失敗の原因となります。
クライアントアプリケーション（上り）またはターゲットサーバー（下り）によって証明書が不明だと検出された場合、以下の手順に従います。
1. 特定のキーストアに格納されている証明書で使われている完全な証明書チェーンを取得します（Router の場合は仮想ホスト構成、Message Processor の場合はターゲットエンドポイント構成を参照してください）。次の API を使用して証明書の詳細を取得できます。
  1. キーストア内の証明書の名前を取得します。
```
    curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs
```
  2. キーストア内の証明書の詳細を取得します
```
    curl -v https://management-server-ip:port/v1/organizations/org-name/environments/env-name/keystores/keystore-name/certs/cert-name
    
```
2. Router（上り）または Message Processor（下り）のキーストアに格納されている証明書が、クライアントアプリケーション（上り）またはターゲットサーバー（下り）のトラストストアに格納されている証明書、あるいは tcpdump 出力から得られる証明書と一致しているかどうかを確認します。不一致があると、それが SSL handshake の失敗の原因となります。
サーバー / クライアントから送信された証明書が期限切れであることが検出された場合、受信側のクライアント / サーバーは証明書を拒否し、tcpdump に次のアラートメッセージが表示されます。
Alert（Level: Fatal, Description: Certificate expired）
該当するホストのキーストアの証明書の有効期限が切れていることを確認します。

解決策

上記の例で識別された問題を解決するには、有効なバックエンドサーバーの証明書を Message Processor のトラストストアにアップロードします。

次の表は、問題の原因に応じて問題を解決するための手順を示しています。

原因	説明	解決策
有効期限が切れた証明書	上り Router のキーストアに格納されている証明書の有効期限が切れています。クライアントアプリケーションのキーストアに格納されている証明書の有効期限が切れています（双方向 SSL）。	新しい証明書とその完全なチェーンを、適切なホストのキーストアにアップロードします。
有効期限が切れた証明書	下りターゲットサーバーのキーストアに格納されている証明書の有効期限が切れています。 Message Processor のキーストアに格納されている証明書の有効期限が切れています（双方向 SSL）。	新しい証明書とその完全なチェーンを、適切なホストのキーストアにアップロードします。
不明な証明書	上りクライアントアプリケーションのトラストストアに格納されている証明書が Router の証明書と一致しません。 Router のトラストストアに格納されている証明書がクライアントアプリケーションの証明書と一致しません（双方向 SSL）。	有効な証明書を適切なホストのトラストストアにアップロードします。
不明な証明書	下りターゲットサーバーのトラストストアに格納されている証明書が Message Processor の証明書と一致しません。 Message Processor のトラストストアに格納されている証明書がターゲットサーバーの証明書と一致しません（双方向 SSL）。	有効な証明書を適切なホストのトラストストアにアップロードします。

SNI が有効になったサーバー

Server Name Indication（SNI）が有効になったサーバーがクライアントと通信するとき、そのクライアントの SNI が無効であれば、TLS/SSL handshake の失敗が発生します。これは、Edge の上り、下りのいずれの接続でも発生する可能性があります。

まず、使用されているサーバーのホスト名とポート番号を識別し、そのサーバーで SNI が有効になっているかどうかを確認する必要があります。

SNI が有効になったサーバーの識別

次のように openssl コマンドを実行します。その際、サーバー名を渡さずに、該当するサーバーホスト名（Edge Router またはバックエンドサーバー）への接続を試みます。
```
    openssl s_client -connect hostname:port
    
```
証明書を取得できることもありますが、次に示すように、openssl コマンドで handshake の失敗が発生することもあります。
```
    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 Router またはバックエンドサーバー）への接続を試みます。
```
    openssl s_client -connect hostname:port -servername hostname
    
```
ステップ 1 で handshake の失敗が発生した場合、またはステップ 1 とステップ 2 で異なる証明書が得られた場合は、この特定のサーバーで SNI が有効であることを示しています。

サーバーで SNI が有効になっていることを確認できたら、以下の手順に従って、クライアントが SNI サーバーと通信できないことが原因で TLS/SSL handshake が失敗したかどうかを検査できます。

診断

上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
tcpdump ユーティリティを実行し、さらに詳しい情報を収集します。
- Private Cloud ユーザーの場合、該当するクライアントまたはサーバーの tcpdump データを収集できます。クライアントは、クライアントアプリ（受信つまり上り接続の場合）、または Message Processor（送信つまり下り接続の場合）である可能性があります。サーバーは、ステップ 1 の判別に応じて Edge Router（受信つまり上り接続の場合）またはバックエンドサーバー（送信つまり下り接続の場合）です。
- Public Cloud ユーザーの場合、Edge Router や Message Processor にアクセスできないので、クライアントアプリ（受信つまり上り接続）またはバックエンドサーバー（送信つまり下り接続）の tcpdump データのみを収集できます。
```
    tcpdump -i any -s 0 host IP address -w File name
    
```
tcpdump コマンドの使用に関する詳細情報については、tcpdump データをご覧ください。
Wireshark または同様のツールを使用して tcpdump データを分析します。
以下に、Wireshark を使った場合の tcpdump の分析例を示します。
1. この例では、Edge Message Processor とバックエンドサーバー（下り接続）の間で TLS/SSL handshake の失敗が発生しました。
2. 以下の tcpdump 出力の 4 番目のメッセージには、Message Processor（送信元）が「Client Hello」メッセージをバックエンドサーバー（宛先）に送信したことが示されています。
3. 「Client Hello」メッセージを選択すると、Message Processor が TLSv1.2 プロトコルを使用していることがわかります。
4. 4 番目のメッセージには、バックエンドサーバーが Message Processor からの「Client Hello」メッセージを認識したことが示されています。
5. バックエンドサーバーは、すぐに「Fatal Alert : Handshake Failure」を Message Processor に送信します（メッセージ 5）。これは、TLS/SSL handshake が失敗し、接続が閉じられるという意味です。
6. 6 番目のメッセージを調べて、次の情報を見つけます。
  - バックエンドサーバーが TLSv1.2 プロトコルをサポートしていること。つまり、Message Processor とバックエンドサーバーの間でプロトコルが一致しています。
  - それにもかかわらず、次の図のように、バックエンドサーバーは「Fatal Alert: Handshake Failure」を Message Processor に送信しています。
7. このエラーは、以下のいずれかの理由で発生した可能性があります。
  - Message Processor が、バックエンドサーバーでサポートされる暗号スイートアルゴリズムを使用していない。
  - バックエンドサーバーで SNI が有効になっているが、クライアントアプリケーションがサーバー名を送信していない。
8. tcpdump 出力の 3 番目のメッセージ（Client Hello）を詳しく調べます。次に示すように、「Extension: server_name」が欠落しています。
9. SNI が有効になっているバックエンドサーバーに Message Processor から server_name が送信されなかったことが、これで確認できました。
10. TLS/SSL handshake が失敗した原因はこれです。この理由で、バックエンドサーバーは「Fatal Alert: Handshake Failure」を Message Processor に送信しました。
SNI が有効になっているサーバーと Message Processor が通信できないことを確かめるために、Message Processor で system.properties の jsse.enableSNIExtension property が false に設定されていることを確認します。

解決策

以下の手順に従って、SNI が有効なサーバーと Message Processor との通信を可能にします。

/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
```

Message Processor を再起動します。

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

複数の Message Processor を使用している場合、すべての Message Processor でステップ 1 から 4 を繰り返します。

TLS/SSL handshake の失敗の原因を特定できず、問題を解決できない場合、または追加のサポートが必要な場合は、Apigee サポートにお問い合わせください。tcpdump 出力とともに、問題に関するあらゆる詳細情報をお知らせください。

TLS/SSL handshake の失敗

症状

エラー メッセージ

考えられる原因

プロトコルの不一致

診断

解決策

暗号の不一致

診断

解決策

正しくない証明書

エラー メッセージ

考えられる原因

ホスト名の不一致

診断

解決策

リファレンス

不完全または正しくない証明書チェーン

診断

解決策

サーバーまたはクライアントから送信された証明書が期限切れまたは不明

診断

解決策

SNI が有効になったサーバー

SNI が有効になったサーバーの識別

診断

解決策

エラーメッセージ

エラーメッセージ