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

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください
情報

内容

クライアント アプリケーションは、Edge Microgateway で API 呼び出しに対するレスポンスとして、502 という HTTP レスポンス コードとメッセージ 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 を初めてセットアップするときに実行する必要があるコマンドの一つは、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 Server(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. Management Server に自己署名証明書がある場合は、それがこの問題の原因です。

解像度

  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 フォルダにある YAML ファイル $HOME/.edgemicro にあります。default.yaml というデフォルトの構成ファイルがあり、ORGENV-config.yaml の環境ごとに 1 つの構成ファイルがあります。影響を受ける組織と環境に対して、このファイルをすべてアップロードしてください。

    リファレンス ドキュメント

    TLS を使用して Edge API にアクセスするように Edge UI を構成する