rest - 通过 AWS API Gateway 代理调用 SSL 端点

Question

目前我的 api 可以通过 SSL 端点访问。我尝试将 aws api 网关配置为将请求代理到我的端点。

我启用了输入传递并将 application/json 设置为内容类型。

无论如何，当我在 aws web interface 上尝试测试请求时，使用 GET 方法获取 SSL URL，如下所示 https://subdomain.domain.com/v1/resource ，我收到以下错误。

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 证书的什么？

感谢任何帮助或线索。

Answer 1

我认为这个问题的答案是您的网络服务器有点微妙的错误配置，浏览器可能会忽略它，但 Java(在 AWS 基础设施中)不会。

这个问题不完全是 SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0 的重复因为它发生在不同的(从您的角度来看)环境中……但我相信这个问题可以解释您所看到的。

现代 TLS (SSL) 堆栈有一个功能可以解决一个古老的问题:在 HTTP over SSL (HTTPS) 中，必要的 SSL 协商发生在请求 header 之前，包括 Host: header ，被发送...并且只能向客户端提供一个 SSL 证书。在引入服务器名称标识 (SNI) 扩展之前，这实际上意味着您的服务器上的每个公共(public) IP 地址只能使用 1 个 SSL 证书，因此如果您有多个域和单独的 SSL 证书，则必须有一个公共(public)的每个证书的 IP 地址，以便 Web 服务器为域名提供正确的证书，因为证书绑定(bind)到服务器配置中的 IP 地址。

现在，至少对于现代浏览器而言，SNI 允许浏览器在服务器发送证书之前向服务器提示其将要请求的主机名......这可能是其中之一，对于不同的域。这消除了每个证书一个静态 IP 的旧的和浪费的做法，因为它允许在服务器正在监听的一个 IP 地址后面配置多个证书。

客户端(在本例中为连接到您的 API 网关的“出站”组件)在 TLS 协商中“先对话”，SNI 在第一条消息中。如果服务器理解消息结构，但不希望看到特定的主机名，则应该返回一个 fatal error ，但它也可以只发送一条警告消息。

该消息可能是警告，看起来很像您在日志中看到的内容。如果 Java TLS 实现是严格的，并且您的服务器以这种方式配置错误(无法识别 SNI 上下文中的主机名，并发送警告而不是错误)，那么我会期望这种行为，即使其他客户端(用户代理库和浏览器)可能会继续 SSL 协商而不会出现明显错误，如果服务器默认提供的证书确实有效并且与域匹配，则“原谅”警告级别的警报。

如果我正确地拼凑了这个难题，您应该能够使用像 tshark 这样的数据包嗅探器来确认此行为，并相应地纠正您的网络服务器的行为。