502 Bad Gateway - 自己署名証明書のチェーン

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。
情報

症状

クライアント アプリケーションは、Edge Microgateway で API 呼び出しに対するレスポンスとして、HTTP レスポンス コード 502 とメッセージ Bad Gateway を受け取ります。

または、管理者が edgemicro configure コマンドを実行すると、self signed certificate in certificate chain エラーが発生します。

エラー メッセージ

クライアントには次のレスポンス メッセージが表示されます。

HTTP/1.1 502 Bad Gateway

エラー レスポンスの一般的な例を 2 つ示します。

{"message":"self signed certificate in certificate chain","code":"SELF_SIGNED_CERT_IN_CHAIN"}
{"message":"self signed certificate","code":"DEPTH_ZERO_SELF_SIGNED_CERT"}

また、edgemicro configure の実行時にこのエラーが発生することもあります。

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

考えられる原因

原因 説明 トラブルシューティングの実施対象
ターゲット サーバーが自己署名証明書を提示する Edge Microgateway はターゲット サーバーの証明書を検証し、信頼できない場合はランタイム エラーを発生させます。 Edge Public Cloud と Private Cloud のユーザー
Apigee Edge Management Server が自己署名証明書を使用している Edge Microgateway を初めて構成するときに、TLS 経由で Apigee Edge に接続してブートストラップを行います。Edge が自己署名証明書を提示すると、これは失敗します。 Edge Private Cloud ユーザー

原因: ターゲット サーバーが自己署名証明書を提示している

南方向接続でターゲット サーバーから 自己署名証明書が提示された場合、Edge Microgateway はデフォルトでこのエラーを発生させます。これは、自己署名証明書を信頼しないためです。

診断

ログ(/var/tmp/edgemicro-`hostname`- *.log)に次のエラーが記録されることがあります。

2021-05-18T10:52:46.425Z [error][0:8000][1][gsc][test][edgemicro_badtargethost][][][2db53f80-
b7c7-11eb-9abe-05b6297863f1][microgateway-core][][GET][502][self signed certificate in certificate
chain][SELF_SIGNED_CERT_IN_CHAIN][]

エラーコード SELF_SIGNED_CERT_IN_CHAIN は、Edge Microgateway がターゲット サーバーから自己署名証明書を受け取った可能性が高いことを示します。これを確認するには、次の手順を行います。

  1. 次の openssl コマンドを実行して、ターゲット サーバーの証明書チェーンを確認します。
    echo | openssl s_client -connect TARGET_SERVER_HOSTNAME:PORT -servername TARGET_SERVER_HOSTNAME | openssl x509 -noout
    
  2. ターゲット サーバーの証明書チェーンが実際に自己署名されている場合、これが問題の原因です。

    次の例では、ターゲット サーバーが自己署名証明書を提示していることに注意してください。

    echo | openssl s_client -connect untrusted-root.badssl.com:443 -servername untrusted-root.badssl.com | openssl x509 -noout
    
    depth=1 C = US, ST = California, L = San Francisco, O = BadSSL, CN = BadSSL Untrusted Root Certificate Authority
    verify error:num=19:self signed certificate in certificate chain
    verify return:0
    DONE

解決策

  1. ターゲット サーバーを所有するチームと協力して、信頼できる認証局(CA)によって署名された適切な TLS 証明書を取得します。
  2. それが不可能な場合は、次のいずれかのオプションを検討して、Edge Microgateway で自己署名証明書を許可します。

    オプション 1: Edge Microgateway がすべての証明書を信頼できるようにシステム プロパティを設定する

    1. docker を使用している場合は、 Node.js によって信頼されていない CA の使用を参照してください。
    2. それ以外の場合は、ルート CA ファイルを指す NODE_EXTRA_CA_CERTS という環境変数をエクスポートします。

      これについては、Node.js の公式ウェブサイトに記載されています。

    オプション 2: 特定のターゲット サーバーの特定の証明書を信頼するように Edge Microgateway YAML 構成ファイルを構成する

    1. ターゲット サーバーの証明書(またはチェーン)が PEM 形式であることを確認します。他の証明書形式を PEM に変換するには、 証明書をサポートされている形式に変換するの手順に沿って操作します。
    2. 証明書チェーンがある場合は、証明書が正しい順序になっていることを確認します。リーフ証明書、中間証明書、ルート証明書の順に指定する必要があります。詳細については、 証明書チェーンの検証をご覧ください。

      次の例では、untrusted-root.badssl.com の信頼できる CA ファイルを構成しています。

      edgemicro:
      ...
      targets:
        - host: 'untrusted-root.badssl.com'
          ssl:
            client
              ca: /opt/apigee/certs/untrusted-root.pem

    この構成の手順については、 Edge Microgateway モジュール - 下り一方向 / 双方向 TLS を構成するの動画でも説明しています。詳細については、 Edge Microgateway サーバーでの SSL の構成を参照してください。

問題が解決しない場合は、診断情報の収集が必要な場合に進みます。

原因: Apigee Edge Management Server が自己署名証明書を使用している

Edge Microgateway を初めて設定するときに実行する必要があるコマンドの 1 つは、edgemicro configure または edgemicro private configure です。このコマンドはクラスタをブートストラップし、Apigee Edge に連絡して必要な情報をダウンロードします。

Edge Private Cloud の場合、Management Server の URL は -m 引数によって決まります。Management Server で TLS を有効にしている場合、Edge Microgateway は Management Server によって提示された証明書の検証を試みます。

Edge Private Cloud の edgemicro configure コマンドの例を次に示します。

edgemicro private configure -u <username> -p <password> -o apigee -e dev -v secure -r https://apigee-dev.net -m https://management.apigee-dev.net:8443

Management Server が自己署名証明書で構成されている場合、コンソール出力に次のエラーが表示されます。

{ Error: self signed certificate in certificate chain
at TLSSocket.onConnectSecure (_tls_wrap.js:1051:34)
at TLSSocket.emit (events.js:189:13)
at TLSSocket._finishInit (_tls_wrap.js:633:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

診断

  1. この場合、管理サーバー(management.apigee-dev.net)が自己署名 TLS 証明書を返している可能性があります。
  2. Apigee Edge システム管理者が証明書を提供し、そのコピーを保持している可能性があります。
  3. それ以外の場合は、次のコマンドを実行して証明書に関する情報を取得します。
    echo | openssl s_client -connect management.apigee-dev.net:8443 -servername management.apigee-dev.net | openssl x509 -noout
    
  4. 管理サーバーに自己署名証明書がある場合、それがこの問題の原因です。

解決策

  1. ターゲット サーバーを所有するチームと協力して、信頼できる認証局(CA)によって署名された適切な TLS 証明書を取得します。
  2. それが不可能な場合は、次の手順で Edge Microgateway で自己署名証明書を許可します。

  3. Edge Microgateway がすべての証明書を信頼できるようにシステム プロパティを設定します。
  4. docker を使用している場合は、 Node.js によって信頼されていない CA の使用を参照してください。
  5. それ以外の場合は、ルート CA ファイルを指す NODE_EXTRA_CA_CERTS という環境変数をエクスポートします。これは、Node.js の公式ウェブサイトに記載されています。

診断情報の収集が必要な場合

上記の手順でも問題が解決しない場合は、次の診断情報を収集して Apigee Edge サポートにお問い合わせください。

  • ログファイル: デフォルトのフォルダは /var/tmp ですが、メインの config.yaml ファイル(logging > dir parameter)でオーバーライドできます。Apigee Edge サポートにログファイルを提供する前に、log > levelinfo に変更することをおすすめします。
  • 構成ファイル: Edge Microgateway のメイン構成は、デフォルトの Edge Microgateway フォルダ $HOME/.edgemicro の YAML ファイルにあります。デフォルトの構成ファイル default.yaml と、各環境の構成ファイル ORG-ENV-config.yaml があります。影響を受ける組織と環境について、このファイルを完全にアップロードします。

    参考ドキュメント

    TLS で Edge API にアクセスするよう Edge UI を構成する