503 Service Unavailable - SSL handshake エラー

API Monitoring

手順 #1: API Monitoring を使用する

API Monitoring を使用してエラーを診断するには:

1. <ph type="x-smartling-placeholder"></ph> Apigee Edge UI にログインするユーザーとして、 付与します。

2. 問題を調査する組織に切り替えます。

   
3. [Analyze] >API モニタリング >Investigate ページをご覧ください。
4. エラーが発生した期間を選択します。

5. 障害コードを Time に対してプロットします。

   <ph type="x-smartling-placeholder">

6. 障害コードが含まれているセルを選択してください messaging.adaptors.http.flow.SslHandshakeFailed: この図にあるとおり 下にあります。

   ( 拡大画像を表示）

   

7. 障害コードに関する情報 messaging.adaptors.http.flow.SslHandshakeFailed は次のように表示されます。 下に示します。

   ( 拡大画像を表示）

   

8. [ログを表示 ] をクリックし、失敗したリクエストの行を開きます。

   ( 拡大画像を表示）

   
9. [ログ] ウィンドウで、次の詳細をメモします。 <ph type="x-smartling-placeholder">
   </ph>
   • リクエスト メッセージ ID
   • ステータス コード: 503
   • 障害の発生元: target
   • 障害コード: messaging.adaptors.http.flow.SslHandshakeFailed

トレース

手順 2: Trace ツールを使用する

Trace ツールを使用してエラーを診断するには:

1. トレース セッションを有効にし、以下のいずれかを行います。 <ph type="x-smartling-placeholder">
   </ph>
   • エラーコードを含む 503 Service Unavailable エラーを待つ messaging.adaptors.http.flow.SslHandshakeFailed が発生する、または
   • 問題を再現できる場合は、API 呼び出しを行って問題を再現してください。 503 Service Unavailable

2. [Show all FlowInfos] が有効になっていることを確認します。

   
3. 失敗したリクエストのいずれかを選択し、トレースを調べます。
4. トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。

5. このエラーは通常、Target Request Flow Started フェーズの後に表示されます。 次のように指定します。

   ( 拡大画像を表示）

   
6. トレースから次の値をメモします。 <ph type="x-smartling-placeholder">
   </ph>
   • エラー: SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.cause: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
   • error.class: com.apigee.errors.http.server.ServiceUnavailableException
   • エラー SSL Handshake failed sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target の値は、SSL handshake が失敗したことを示します。 これは、Apigee Edge の Message Processor でバックエンド サーバーの あります。
7. トレースの [AX（Analytics Data Recorded）] フェーズに移動してクリックします。

8. [Phase Details Error Headers] セクションまで下にスクロールし、 X-Apigee-fault-codeX-Apigee-fault-code と X-Apigee-fault-sourceX-Apigee-fault-code の値 X-Apigee-Message-ID を使用します。

   ( 拡大画像を表示）

   
9. X-Apigee-fault-code、X-Apigee-fault-source、 X-Apigee-Message-ID:

エラーヘッダー	値
X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
X-Apigee-fault-source	target
X-Apigee-Message-ID	MESSAGE_ID

NGINX

手順 #3: NGINX アクセスログを使用する

NGINX アクセスログを使用してエラーを診断するには:

1. Private Cloud ユーザーの場合は、NGINX アクセスログを使用して、 HTTP 503 Service Unavailable に関する重要な情報。

2. NGINX アクセスログを確認します。

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

   <ph type="x-smartling-placeholder">
3. エラーコードを含む 503 エラーがないか検索します 特定の期間にmessaging.adaptors.http.flow.SslHandshakeFailed （ または、まだ 503 で失敗しているリクエストがあるかどうか。

4. X-Apigee-fault-code と一致する 503 エラーが見つかった場合 messaging.adaptors.http.flow.SslHandshakeFailed の値、 X-Apigee-fault-source. の値を確認します。

   NGINX アクセスログの 503 エラーの例:

   ( 拡大画像を表示）

   

   NGINX アクセスログの上記のサンプル エントリには、次の値が含まれます。 X-Apigee-fault-code と X-Apigee-fault-code

   ヘッダー	値
   X-Apigee-fault-code	messaging.adaptors.http.flow.SslHandshakeFailed
   X-Apigee-fault-source	target

Message Processor のログ

手順 4: Message Processor のログの使用

1. 失敗したリクエストのメッセージ ID を特定するには、API Monitoring、Trace ツール、 一般的な診断手順で説明しているように、NGINX Access Logs を使用します。

2. Message Processor ログで特定のリクエスト メッセージ ID を検索する （/opt/apigee/var/log/edge-message-processor/logs/system.log）。ご覧のとおり、 次のエラーが発生します。

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context.handshakeFailed() :
   SSLClientChannel[Connected: Remote:X.X.X.X:443
   Local:192.168.194.140:55102]@64596 useCount=1
   bytesRead=0 bytesWritten=0 age=233ms  lastIO=233ms
   isOpen=true handshake failed, message: General SSLEngine problem
   

   上記のエラーは、Message Processor 間で SSL handshake が失敗したことを示します。 バックエンドサーバーと通信します

   その後、次のように、詳細なスタック トレースを含む例外が発生します。

   org:myorg env:test api:MyProxy rev:1
   messageid:myorg-28247-3541813-1
   NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onException() :
   RequestWriteListener.onException(HTTPRequest@1522922c)
   javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478)
   	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535)
   	... <snipped>
   Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
   	at sun.security.ssl.Alerts.getSSLException(Alerts.java:203)
   	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
   	... <snipped>
   Caused by: sun.security.validator.ValidatorException: PKIX path building failed:
   sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
   certification path to requested target
   	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
   	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
   	... <snipped>
     

   handshake の失敗の原因は次のとおりです。

   Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

   これは、Apigee Edge の Message Processor で SSL handshake が失敗したことを示します。 バックエンド サーバーの証明書を検証できません。

フェーズ 1

フェーズ 1: バックエンド サーバーの証明書チェーンを決定する

次のいずれかの方法を使用して、バックエンド サーバーの証明書チェーンを決定します。

openssl s_client -connect BACKEND_SERVER_HOST_NAME:PORT#

Certificate chain
 0 s:/CN=mocktarget.apigee.net
   i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
 1 s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
 2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
   i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1

フェーズ 2

フェーズ 2: バックエンド サーバーの証明書と、 Message Processor のトラストストア

1. バックエンド サーバーの証明書チェーンを決定します。
2. 次を使用して、Message Processor のトラストストアに保存されている証明書を特定します。 次のとおりです。 <ph type="x-smartling-placeholder">
   </ph>

   1. TrustStore 要素からトラストストア参照名を取得する TargetEndpoint の SSLInfo セクションにあります。

      TargetEndpoint の SSLInfo セクションのサンプルを見てみましょう。 構成:

      <TargetEndpoint name="default">
      ...
         <HTTPTargetConnection>
            <Properties />
            <SSLInfo>
               <Enabled>true</Enabled>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <KeyStore>ref://myKeystoreRef</KeyStore>
               <KeyAlias>myKey</KeyAlias>
               <TrustStore>
                  ref://myCompanyTrustStoreRef
               </TrustStore>
            </SSLInfo>
         </HTTPTargetConnection>
         ...
      </TargetEndpoint>
      

   2. 上記の例では、TrustStore 参照名は次のようになります。 myCompanyTruststoreRef。

   3. Edge UI で、[Environments >参照。スペース内の名前を 特定のトラストストア参照の Reference 列。これがお客様の トラストストア名を指定します。

      ( 拡大画像を表示）

      

   4. 上記の例では、トラストストア名は次のようになります。

      myCompanyTruststoreRef: myCompanyTruststore

3. トラストストアに保存されている証明書を取得します（前のステップで特定）。 次の API を使用します。

   1. <ph type="x-smartling-placeholder"></ph> キーストアまたはトラストストアのすべての証明書を取得する。この API は、 作成する必要があります。

      Public Cloud ユーザー:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      Private Cloud ユーザー:

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs -H "Authorization: Bearer $TOKEN"
      

      ここで:

      • ORGANIZATION_NAME は組織の名前です。
      • ENVIRONMENT_NAME は、環境の名前です。
      • KEYSTORE_NAME はキーストアの名前です。
      • $TOKEN は OAuth 2.0 アクセストークンに設定されます OAuth 2.0 アクセス トークンを取得する
      • この例で使用されている curl オプションについては、 curl を使用する

      出力例:

      サンプルのトラストストア myCompanyTruststore からの証明書は次のとおりです。

      [
        "serverCert"
      ]
      

   2. <ph type="x-smartling-placeholder"></ph> キーストアまたはトラストストアから特定の証明書の証明書の詳細を取得する。 この API は、特定の証明書の特定の証明書に関する情報を返します。 できます。

      Public Cloud ユーザー:

      curl -v -X GET https//api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      Private Cloud ユーザー

      curl -v -X GET http://MANAGEMENT_HOST:PORT_#>/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/keystores/KEYSTORE_NAME/certs/CERT_NAME -H "Authorization: Bearer $TOKEN"
      

      ここで:

      • ORGANIZATION_NAME は組織の名前です。
      • ENVIRONMENT_NAME は、環境の名前です。
      • KEYSTORE_NAME はキーストアの名前です。
      • CERT_NAME は、証明書の名前です。
      • $TOKEN は、OAuth 2.0 アクセストークンに設定されます。 OAuth 2.0 アクセス トークンを取得する
      • この例で使用されている curl オプションについては、 curl を使用する

      出力例:

      serverCert の詳細には、サブジェクトと発行者が次のように表示されます。

      リーフ/エンティティ証明書:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      中間証明書:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

4. 手順 1 で取得した実際のサーバー証明書と証明書が、 ステップ 3 で取得したトラストストアに格納された値が一致します。一致しない場合、 問題の原因を特定します。

   上記の例で、一度に 1 つの証明書について見てみましょう。

   1. リーフ証明書:

      バックエンド サーバーから:

      s:/CN=mocktarget.apigee.net
      i:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      

      Message Processor（クライアント）のトラストストアから:

      "subject": "CN=mocktarget.apigee.net",
      "issuer": "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      

      トラストストアに保存されているリーフ証明書がバックエンドのリーフ証明書と一致する あります。

   2. 中間証明書:

      バックエンド サーバーから:

      s:/C=US/O=Google Trust Services LLC/CN=GTS CA 1D4
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      Message Processor（クライアント）のトラストストアから:

      "subject" : "CN=GTS CA 1D4, O=Google Trust Services LLC, C=US",
      "issuer" : "CN=GTS Root R1, O=Google Trust Services LLC, C=US",
      

      トラストストアに格納されている中間証明書が、 バックエンドサーバーと通信します

   3. ルート証明書:

      バックエンド サーバーから:

      s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
      

      Message Processor のイメージにルート証明書が完全に できます。

   4. ルート証明書がトラストストアに存在しないため、 Message Processor は次の例外をスローします。

      sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
      

      503 Service Unavailable とエラーコードを返す クライアントへの messaging.adaptors.http.flow.SslHandshakeFailed 説明します。

正しい FQDN

バックエンド サーバーのキーストアを、正しい FQDN、有効かつ完全な証明書で更新する チェーン:

1. 正しい FQDN を持つバックエンド サーバーの証明書がない場合は、 次に、適切な CA（認証局）から適切な証明書を入手します。

2. 以下を確認します。 バックエンド サーバーの証明書チェーンが有効で完全なものになります。

   <ph type="x-smartling-placeholder">
3. 正しい FQDN を持つ有効な完全な証明書チェーンが ホスト名と同一のリーフ証明書またはエンティティ証明書のバックエンド サーバーを 使用している場合は、バックエンドのキーストアを 完全な証明書チェーンです。

正しいバックエンド サーバー

正しいバックエンド サーバーのホスト名を使用して、ターゲット エンドポイントを更新します。

1. ターゲット エンドポイントのホスト名が正しく指定されていない場合は、 バックエンドの FQDN と一致する正しいホスト名を持つターゲット エンドポイント 表示されます。

2. API プロキシへの変更を保存します。

   上記の例で、バックエンド サーバーのホスト名が正しくない場合、 バックエンド サーバーの証明書の FQDN を使用して修正できます。 つまり、次のように backend.apigee.net です。

   <TargetEndpoint name="default">
      …
      <HTTPTargetConnection>
         <Properties />
         <SSLInfo>
            <Enabled>true</Enabled>
            <TrustStore>ref://myTrustStoreRef</TrustStore>
         </SSLInfo>
         <URL>https://backend.apigee.net/resource</URL>
      </HTTPTargetConnection>
   </TargetEndpoint>