API 网关 - ALB：主机名/IP 与证书的替代名称不匹配

Posted 2023-03-07

【中文标题】API 网关 - ALB：主机名/IP 与证书的替代名称不匹配

【英文标题】：API Gateway - ALB: Hostname/IP doesn't match certificate's altnames

【发布时间】：2019-02-01 00:57:16

【问题描述】：

我目前的设置如下：

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

我还在 API 网关上设置了自定义域名（更新：我使用了默认的 API 网关链接并遇到了同样的问题，我认为这不是自定义域问题）

当 ECS 集群中的 1 个服务通过 API 网关调用另一个服务时，我得到 ​​p>

主机名/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"

当我直接在 Postman 上调用底层 API 网关 URL 时，它可以工作......不知何故，它让我想起了 CORS，其中服务器似乎阻止了我的服务器 localhost 或 ECS/ELB 访问我的 API 网关？

---

这可能很混乱，所以总结一下我的尝试：

在现有设置中，ECS 内的服务可能会通过 API 网关调用另一个服务。发生这种情况时，由于 HTTPS 错误而失败 为了解决这个问题，我设置了rejectUnauthorized: false，但是API网关返回HTTP 403 在localhost上运行时，报错类似 我尝试调用 ELB 而不是 API 网关，它可以工作...

【问题讨论】：

我没有任何真正的见解，但也许检查内部与外部 IP 和 DNS 可能是一个开始？

@akaphenom 但我应该将什么严格视为问题？我的 ALB 是面向公众的。我应该查看什么 IP 或 DNS 设置？

你可以试试process.env.NODE_TLS_REJECT_UNAUTHORIZED = false

看起来像一个配置问题，如果您有支持计划，也许可以联系 aws 支持？我不会在这里推荐任何解决方案，因为如果你首先设置它，你实际上不应该禁用 https 检查或上面评论中的标志。这是一个糟糕的黑客行为。我没有看到其他人面临这个问题，所以您可能应该询问 aws 团队。很可能是一些配置问题

您的设置中的 Host: someid.ap-southeast-1.elb.amazonaws.com 是什么？

【参考方案1】：

有多种变通方法会带来安全隐患，而不是提供适当的解决方案。为了修复它，您需要将someid.ap-southeast-1.elb.amazonaws.com. 的CNAME 条目添加到DNS（此条目可能已经存在）以及一个SSL 证书，就像在Adding an Alternate Domain Name 的AWS 文档中描述的一样。这可以通过CloudFront 控制台和ACM 来完成。关键是，对于当前的证书，备用（内部！！）主机名将永远不会与证书匹配，证书只能覆盖一个 IP - 因此它更多的是基础设施问题，而不是代码问题.

再次查看时...而不是扩展面向公众的接口的 SSL 证书 - 更好的解决方案可能是使用单独的 SSL 证书，用于 API 网关和 ALB 之间的通信，根据这个guide；在这种情况下，甚至自签名也是可能的，因为任何外部客户端都不会访问证书。

关于HTTP403 docs 阅读：

您配置了一个 AWS WAF Web 访问控制列表 (Web ACL) 来监控对您的 Application Load Balancer 的请求，但它阻止了一个请求。

我希望这有助于设置端到端加密，而 API 网关只有一个面向公众的接口需要 CA 证书，对于任何内部通信，自签名就足够了。

这个article 是关于ELB 和ALB 之间的差异 - 虽然它可能值得考虑，如果确实为给定场景选择了最合适的负载均衡器。如果不需要基于内容的路由，减少无用的复杂性可能会有所帮助。这将消除定义路由规则的需要......您还应该查看一次，以防坚持ALB。我的意思是，这些问题只显示了基本场景和一些失败的代码，而不是路由规则。