13

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)

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

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"

Why is this?

UPDATE

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

{
    "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: 

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?

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
  • To resolve it, I set rejectUnauthorized: false, but API gateway returns HTTP 403
  • When running on localhost, the error is similar
  • I tried calling ELB instead of API gateway, it works ...
Jiew Meng
  • 84,767
  • 185
  • 495
  • 805
  • I don't have any real insight but perhaps checking Internal versus external IP and DNS might be a start? – akaphenom Aug 26 '18 at 11:24
  • @akaphenom but what exacting should I deem as a problem? My ALB is public facing. What IP or DNS setting should I be looking at? – Jiew Meng Aug 27 '18 at 10:48
  • Can you try `process.env.NODE_TLS_REJECT_UNAUTHORIZED = false` – Kush Vyas Aug 28 '18 at 12:19
  • looks like a configuration issue, Maybe contact aws support if you have a support plan? i wouldn't recommend any of the solutions here since you shouldn't actually disable https check or the flag from the comment above this if you set it up in the first place. That is a bad hack. I don't see others facing this issue so you should probably ask aws team. Most probably some configuration issue – itaintme Aug 30 '18 at 17:45
  • What is Host: someid.ap-southeast-1.elb.amazonaws.com in your setup? – carlsborg Aug 30 '18 at 23:50
  • Can you add the details of the certificates involved? – Josnidhin Aug 31 '18 at 02:51
  • @carlsborg its the ALB URL – Jiew Meng Sep 01 '18 at 13:17
  • @Josnidhin, what certs? You mean SSL cert? I actually am using HTTP Proxy to HTTP ALB URL and not HTTPS – Jiew Meng Sep 01 '18 at 13:18
  • possibly this might helpful https://stackoverflow.com/questions/14262986/node-js-hostname-ip-doesnt-match-certificates-altnames – Atul Agrawal Sep 01 '18 at 18:38

1 Answers1

5

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.

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.

Concerning that HTTP403 the docs read:

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

I 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.

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.

Martin Zeitler
  • 1
  • 19
  • 155
  • 216