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

My setup currently looks like:

我的设置目前看起来像:

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

I also have a custom domain name set on API Gateway (UPDATE: I used the default API gateway link and got the same problem, I don't think this is a custom domain issue)

我还在API网关上设置了自定义域名(UPDATE:我使用了默认的API网关链接并遇到了同样的问题,我认为这不是自定义域名问题)

When 1 service in ECS cluster calls another service via API gateway, I get

当ECS集群中的1个服务通过API网关调用另一个服务时,我得到了

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

主机名/ IP与证书的altnames不匹配:“Host:someid.ap-southeast-1.elb.amazonaws.com。不在证书的altnames中:DNS:*。execute-api.ap-southeast-1.amazonaws。 COM”

Why is this?

为什么是这样?

UPDATE

I notice when I start a local server that calls the API gateway I get a similar error:

我注意到当我启动调用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\""
}

And if I try to disable the HTTPS check:

如果我尝试禁用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!
  })
})

I get this instead ...

我得到了这个......

{
    "message": "Forbidden"
}

When I call the underlying API gateway URL directly on Postman it works ... somehow it reminds me of CORS, where the server seems to be blocking my server either localhost or ECS/ELB from accessing my API gateway?

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

It maybe quite confusing so a summary of what I tried:

它可能很混乱,所以我尝试的总结:

In the existing setup, services inside ECS may call another via API gateway. When that happens it fails because of the HTTPS error

在现有设置中,ECS内的服务可以通过API网关调用另一个。发生这种情况时,由于HTTPS错误而失败

To resolve it, I set rejectUnauthorized: false, but API gateway returns HTTP 403

要解决它,我设置rejectUnauthorized:false,但API网关返回HTTP 403

When running on localhost, the error is similar

在localhost上运行时,错误类似

I tried calling ELB instead of API gateway, it works ...

我试过调用ELB而不是API网关,它的工作原理......

1 个解决方案

#1

there are various workarounds, which introduce security implications, instead of providing a proper solution. in order to fix it, you need to add a CNAME entry for someid.ap-southeast-1.elb.amazonaws.com. to the DNS (this entry might already exists) and also to one SSL certificate, alike it is being described in the AWS documentation for Adding an Alternate Domain Name. this can be done with the CloudFront console & ACM. the point is, that with the current certificate, that alternate (internal !!) host-name will never match the certificate, which only can cover a single IP - therefore it's much more of an infrastructural problem, than it would be a code problem.

有各种解决方法,它们会引入安全隐患,而不是提供适当的解决方案。为了解决这个问题,您需要为someid.ap-southeast-1.elb.amazonaws.com添加CNAME条目。到DNS(此条目可能已经存在)以及一个SSL证书,类似于AWS文档中有关添加备用域名的描述。这可以通过CloudFront控制台和ACM完成。关键是,使用当前证书,备用(内部!!)主机名永远不会匹配证书,证书只能覆盖单个IP - 因此它更多的是基础设施问题,而不是代码问题。

when reviewing it once again... instead of extending the SSL certificate of the public-facing interface - a better solution might be to use a separate SSL certificate, for the communication in between the API Gateway and the ALB, according to this guide; even self-signed is possible in this case, because the certificate would never been accessed by any external client.

再次审阅时...根据本指南,更好的解决方案可能是使用单独的SSL证书,用于API网关和ALB之间的通信,而不是扩展面向公众的界面的SSL证书;在这种情况下,甚至可以进行自签名,因为任何外部客户端都不会访问证书。

concerning that HTTP403 the docs read:

关于HTTP403文档的内容:

You configured an AWS WAF web access control list (web ACL) to monitor requests to your Application Load Balancer and it blocked a request.

您配置了AWS WAF Web访问控制列表(Web ACL)以监视对应用程序负载均衡器的请求,并阻止了请求。

hope this helps setting up end-to-end encryption... while only the one public-facing interface of the API gateway needs a CA certificate, for whatever internal communication, self-signed should suffice.

希望这有助于设置端到端加密...虽然只有API网关的一个面向公众的接口需要CA证书,但对于任何内部通信,自签名都应该足够。

this article is about the difference in between ELB and ALB - while it might be worth a consideration, if indeed the most suitable load-balancer for the given scenario had been chosen. in case no content-based routing is required, cutting down on useless complexity might be helpful. this would eliminate the need to define the routing rules ...which you should also review once, in case sticking to ALB. I mean, the questions only shows the basic scenario and some code which fails, but not the routing rules.

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

#1