web-dev-qa-db-ja.com

APIゲートウェイ-ALB：ホスト名/ IPが証明書の代替名と一致しません

私のセットアップは現在次のようになっています：

API Gateway --- ALB --- ECS Cluster --- NodeJS Applications
             |    
             -- Lambda

API Gatewayにもカスタムドメイン名を設定しています（更新：デフォルトのAPIゲートウェイリンクを使用しましたが、同じ問題が発生しました。これはカスタムドメインの問題ではないと思います）

ECSクラスター内の1つのサービスがAPIゲートウェイを介して別のサービスを呼び出すと、

ホスト名/ IPが証明書の代替名と一致しません： "ホスト：someid.ap-southeast-1.elb.amazonaws.com。が証明書の代替名にありません：DNS：*。execute-api.ap-southeast-1.amazonaws。 com」

どうしてこれなの？

[〜＃〜]更新[〜＃〜]

APIゲートウェイを呼び出すローカルサーバーを起動すると、同様のエラーが発生します。

{
    "error": "Hostname/IP doesn't match certificate's altnames: \"Host: localhost. is not in the cert's altnames: DNS:*.execute-api.ap-southeast-1.amazonaws.com\""
}

そして、HTTPSチェックを無効にしようとすると：

const response = await axios({
  method: req.method,
  url,
  baseURL,
  params: req.params,
  query: req.query,
  data: body || req.body,
  headers: req.headers,
  httpsAgent: new https.Agent({
   : false // <<=== HERE!
  })
})

代わりにこれを取得します...

{
    "message": "Forbidden"
}

基盤となるAPIゲートウェイURLをPostmanで直接呼び出すと、機能します...どういうわけか、サーバーがローカルホストまたはECS/ELBのいずれかのサーバーがAPIゲートウェイにアクセスするのをブロックしているように見えるCORSを思い出させますか？

それはおそらくかなり混乱しているので、私が試したことの要約：

  • 既存の設定では、ECS内のサービスがAPIゲートウェイを介して別のサービスを呼び出す場合があります。それが発生すると、HTTPSエラーのために失敗します
  • これを解決するために、rejectUnauthorized: falseを設定しましたが、APIゲートウェイはHTTP403を返します
  • ローカルホストで実行している場合、エラーは同様です
  • APIゲートウェイの代わりにELBを呼び出してみましたが、機能します...
node.jsamazon-web-serviceshttpsaws-api-gatewayamazon-elb
9
Jiew Meng

適切なソリューションを提供する代わりに、セキュリティへの影響をもたらすさまざまな回避策があります。これを修正するには、someid.ap-southeast-1.elb.amazonaws.com.のCNAMEエントリをDNS（このエントリはすでに存在している可能性があります）と1つのSSL証明書に追加する必要があります。これはAWSのドキュメントで説明されています。 for 代替ドメイン名の追加 。これは、 CloudFront console＆ [〜＃〜] acm [〜＃〜] で実行できます。重要なのは、現在の証明書では、その代替（内部!!）ホスト名が証明書と一致することはなく、単一のIPしかカバーできないため、コードの問題よりもインフラストラクチャの問題の方がはるかに多いということです。 。

もう一度確認するとき...公開インターフェースのSSL証明書を拡張する代わりに、これによると、APIゲートウェイとALB間の通信に別のSSL証明書を使用する方が良い解決策かもしれません- ガイド ;この場合、外部クライアントが証明書にアクセスすることはないため、自己署名も可能です。

それについてHTTP403docs 読む：

アプリケーションロードバランサーへのリクエストを監視するようにAWSWAF Webアクセスコントロールリスト（Web ACL）を設定し、リクエストをブロックしました。

これがエンドツーエンド暗号化の設定に役立つことを願っています... APIゲートウェイの1つの公開インターフェースのみがCA証明書を必要としますが、内部通信が何であれ、自己署名で十分です。

これ 記事 はELBとALBの違いについてですが、実際に特定のシナリオに最も適したロードバランサーがあれば、検討する価値があるかもしれません。選ばれました。コンテンツベースのルーティングが必要ない場合は、無駄な複雑さを減らすことが役立つ場合があります。これにより、ルーティングルールを定義する必要がなくなります... ALBに固執する場合は、ルーティングルールも一度確認する必要があります。つまり、質問には基本的なシナリオと失敗するコードのみが表示され、ルーティングルールは表示されません。

1
Martin Zeitler