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 クライアントとサーバーが通信で使用できる秘密鍵が確立します。このプロセスが行われる間、クライアントとサーバーでは以下が実行されます。

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

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 の失敗が発生します。上りと下りの接続についてもご覧ください。

診断

  1. 上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
  2. 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 データをご覧ください。
  3. Wireshark ツールまたは同様のツールを使用して tcpdump データを分析します。
  4. 以下に、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 プロトコルをサポートしていない場合、この問題を解決するには、以下の手順のいずれかを行います。

  1. TLSv1.2 プロトコルをサポートするように、バックエンド サーバーをアップグレードします。プロトコル TLSv1.2 の安全性は高いので、この解決策をおすすめします。
  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 の失敗が発生します。上りと下りの接続についてもご覧ください。

診断

  1. 上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
  2. 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 データをご覧ください。
  3. Wireshark ツールを使用するか、使い慣れた類似のツールがあればそれを使用して tcpdump データを分析します。
  4. 以下に、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 のユーザー

ホスト名の不一致

診断

  1. 次の Edge 管理 API 呼び出しによって返される URL で使われているホスト名を確認します。
    curl -v https://myorg.domain.com/v1/getinfo
    例:
    curl -v https://api.enterprise.apigee.com/v1/getinfo
  2. 特定のキーストアに格納されている証明書で使われている CN を取得します。次の Edge 管理 API を使用して証明書の詳細を取得できます。
    1. キーストア内の証明書の名前を取得します。

      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
          
    2. 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 を使用する証明書を取得します(まだ取得していない場合)。その後、完全な証明書チェーンをキーストアにアップロードします。

リファレンス

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

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

診断

  1. 特定のキーストアに格納されている証明書で使われている 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. 以下の図は、中間証明書とルート証明書が一致しない無効な証明書チェーンを含む証明書の例です。
    5. 発行元とサブジェクトが一致しない中間証明書とルート証明書の例


解決策

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

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

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

診断

  1. 上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
  2. 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 データをご覧ください。
  3. Wireshark または同様のツールを使用して tcpdump データを分析します。
  4. tcpdump 出力から、検証ステップで証明書を拒否しているホスト(クライアントまたはサーバー)を特定します。
  5. データが暗号化されていなければ、もう一方の側から送信された証明書を tcpdump 出力から取得できます。これは、この証明書と、トラストストアで入手可能な証明書が一致するかどうかを比較するのに役立ちます。
  6. 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」セクションの下にすべて表示されます。
  7. 上記の例のように、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 の失敗の原因となります。
  8. クライアント アプリケーション(上り)またはターゲット サーバー(下り)によって証明書が不明だと検出された場合、以下の手順に従います。
    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 の失敗の原因となります。
  9. サーバー / クライアントから送信された証明書が期限切れであることが検出された場合、受信側のクライアント / サーバーは証明書を拒否し、tcpdump に次のアラート メッセージが表示されます。

    Alert(Level: Fatal, Description: Certificate expired)

  10. 該当するホストのキーストアの証明書の有効期限が切れていることを確認します。

解決策

上記の例で識別された問題を解決するには、有効なバックエンド サーバーの証明書を 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 が有効になったサーバーの識別

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

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

診断

  1. 上りまたは下りのどちらの接続でエラーが発生しているかを特定します。この特定方法の詳細なガイダンスについては、問題の原因の特定をご覧ください。
  2. 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 データをご覧ください。
  3. Wireshark または同様のツールを使用して tcpdump データを分析します。
  4. 以下に、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 に送信しました。
  5. SNI が有効になっているサーバーと Message Processor が通信できないことを確かめるために、Message Processor で system.propertiesjsse.enableSNIExtension property が false に設定されていることを確認します。

解決策

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

  1. /opt/apigee/customer/application/message-processor.properties ファイルを作成します(まだ存在しない場合)。
  2. このファイルに次の行を追加します。 conf_system_jsse.enableSNIExtension=true
  3. chown を実行してこのファイルの所有者を apigee:apigee にします。
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Message Processor を再起動します。
    /opt/apigee/apigee-service/bin/apigee-service message-processor restart
  5. 複数の Message Processor を使用している場合、すべての Message Processor でステップ 1 から 4 を繰り返します。

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