I have a lambda function behind an api gateway. This is working fine when triggered with an Invoke URL. Invoke URL is the link offered in method tab under stages.
I am sending request to the resource as below, and this works fine.
I want to set a custom domain for my api so I followed the standard procedure to set an ACM certificate. In addition to that I did set domain (api.tarkshala.com) in route53. Check screenshots given below.
ACM certificate imported
Custom domain mapping
Domain name mapped in route53
But when I hit the API using cloudfront link(d3pn2j4magp6tp.cloudfront.net) or the domain name (api.tarkshala.com) using POSTMAN, it ends up into 403 Forbidden.
I don't know what exactly am I missing?
Response Header looks as following:
Connection →keep-alive
Content-Length →23
Content-Type →application/json
Date →Fri, 13 Apr 2018 03:17:25 GMT
Via →1.1 a1cf0e6cf29b584b5fe1ada9ccee9758.cloudfront.net (CloudFront)
X-Amz-Cf-Id →9Jh5HeQIuDNfm5WGlTae34oYZ7BiN3nI2VlH_8PJHLQ0mr2C20njJQ==
X-Cache →Error from cloudfront
x-amz-apigw-id →FQoiyF1phcwFVrg=
x-amzn-ErrorType →ForbiddenException
x-amzn-RequestId →3013c239-3ec9-11e8-abe6-53449bcfc96c
Response:
{
"message": "Forbidden"
}
A custom origin is returning the 403 error To troubleshoot, make the request directly to the origin. If you can replicate the error without CloudFront, then the origin is causing the 403 error. If the error is caused by the custom origin, then check the origin logs to identify what might be causing the error.
The HTTP 403 Forbidden error most commonly occurs when private DNS is enabled for an API Gateway interface VPC endpoint that's associated with a VPC. In this scenario, all requests from the VPC to API Gateway APIs resolve to that interface VPC endpoint.
The documentation doesn't seem to mention an important aspect of the configuration of the CloudFront distribution associated with an API Gateway endpoint... it seems it can only be inferred:
When you create a custom domain name for an edge-optimized API, API Gateway sets up a CloudFront distribution. But you must set up a DNS record to map the custom domain name to the CloudFront distribution domain name [in order] for API requests bound for the custom domain name to be [correctly] routed to API Gateway through the mapped CloudFront distribution [and understood when they arrive]. You must also provide a certificate for the custom domain name. (emphasis added, bracketed words are mine, added for clarity)
https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html
Internally, CloudFront distributions have two ways of handling the Host
header that arrives on the incoming request -- CloudFront can hand over the Host
header submitted by the browser, if it is on a list of expected values, or can always pass a single static value to the back-end origin that it infers from the origin configuration.
For the CloudFront distributions managed by API Gateway, the configuration is apparently to pass through what the browser sends, which makes a good deal of sense because the other alternative would require API Gateway to engage in additional manipulation of the incoming request that would be convoluted and complicated, to say the very least.
Thus, to test a custom domain name on an API Gateway deployment, the requester must include the custom domain name as the HTTP Host
header. The cloudfront.net alias target hostname is used only for DNS mapping -- it isn't an alternate hostname that API Gateway actually associates with your deployed stage when processing incoming requests.
If your custom domain name is pointed to the "target" domain name in DNS, and you access the API via the custom domain, this all happens automatically. Otherwise, you can set the Host
header manually, for testing, if the tool you are using will allow it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With