3

現在、私の API は SSL エンドポイント経由でアクセスできます。リクエストをエンドポイントにプロキシするように aws api ゲートウェイを設定しようとしました。

入力パススルーを有効にし、application/json を content-type として設定しました。

いずれにせよ、AWS Web インターフェイスでテスト リクエストを試行すると、 https://subdomain.domain.com/v1/resourceのような SSL URL への GET メソッドを使用して、次のエラーが発生します。

Execution log for request test-request
Thu Aug 06 06:55:27 UTC 2015 : Starting execution for request: test-invoke-request
Thu Aug 06 06:55:27 UTC 2015 : API Key: test-invoke-api-key
Thu Aug 06 06:55:27 UTC 2015 : Method request path: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request query string: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request headers: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request body before transformations: null
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request URI: https://xyz.domain.com/v1/resource
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request headers: {Accept=application/json, User-Agent=AmazonAPIGateway_6cb3krv5t9}
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request body after transformations: 
Thu Aug 06 06:55:27 UTC 2015 : Execution failed due to configuration error: handshake alert: unrecognized_name

SSL 証明書に欠けているものは何ですか?

どんな助けや手がかりも大歓迎です。

4

2 に答える 2

4

これに対する答えは、ブラウザが無視する傾向があるウェブサーバーのやや微妙な設定ミスだと思いますが、Java (AWS インフラストラクチャ内) はそうではありません。

質問は、SSLハンドシェイクアラートの正確な複製ではありません:Java 1.7.0へのアップグレード以降のunrecognized_nameエラーは、別の(あなたの観点から)環境で発生しているためです...しかし、その質問はあなたが見ているものを説明していると思います.

最新の TLS (SSL) スタックには、古くからの問題に対する解決策を提供する機能があります。HTTP over SSL (HTTPS) では、ヘッダーを含む要求ヘッダーHost:が送信される前に、必要に応じて SSL ネゴシエーションが行われます...クライアントに提供できる SSL 証明書は 1 つだけです。Server Name Identification (SNI) 拡張機能が導入される前は、これは基本的に、サーバーのパブリック IP アドレスごとに 1 つの SSL 証明書に制限されていたことを意味していました。証明書はサーバー構成で IP アドレスにバインドされているため、Web サーバーがドメイン名の正しい証明書を提供するように、各証明書の IP アドレス。

現在、少なくとも最新のブラウザーでは、SNI を使用すると、サーバーが証明書を送信する前に、ブラウザーが要求を行うホスト名に関するヒントをサーバーに与えることができます。 . これにより、サーバーがリッスンしている 1 つの IP アドレスだけで複数の証明書を構成できるため、証明書ごとに 1 つの静的 IP という古くて無駄な慣行がなくなります。

クライアント (この場合、あなたに接続する API Gateway の「アウトバウンド」コンポーネント) は TLS ネゴシエーションで「最初に対話」し、SNI は最初のメッセージにあります。サーバーがメッセージの構造を理解しているが、その特定のホスト名が表示されることを期待していない場合、致命的なエラーが返さ れるはずですが、警告メッセージのみを送信することもできます。

おそらく警告であるそのメッセージは、ログに表示されているものとよく似ているようです。Java TLS 実装が厳密であり、サーバーがこのように誤って構成されている場合 (SNI のコンテキストでホスト名を認識せず、エラーではなく警告を送信する)、他のクライアントであっても、まさにこの動作を期待します。 (ユーザー エージェント ライブラリとブラウザー) は、サーバーがデフォルトで提供する証明書が実際に有効であり、ドメインと一致する場合、警告レベルのアラートを「許容」して、明らかなエラーなしで SSL ネゴシエーションを続行することができます。

このパズルを正しく組み立てれば、 のようなパケット スニファでこの動作を確認し、tsharkそれに応じて Web サーバーの動作を修正できるはずです。

于 2015-08-20T00:59:58.763 に答える
0

API Gatewayこれは、チームの誰かにとって非常に具体的な質問のようです。ここのコミュニティは、これに関してあなたを本当に助けることはできません. AWS フォーラムのAPI Gateway セクションから AWS に連絡してみてください。

于 2015-08-19T22:11:05.310 に答える