Blog
Token
About Us
AiDOOS Wiki
Project Cost Estimation

Welcome to Knowledge Base!

KB at your finger tips

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All
CRM
Salesforce
ERP
SAP
Storage and Backups
Purestorage Netapp Nutanix
Cloud
AWS
Computing
IBM
Database
MongoDB MySQL PostgreSQL
DevOps
Docker Kubernetes Jenkins GitLab
Mobile
React Native Android
Web
React Angular PHP
Programming
Python
Products
CNC Software (Mastercam) 3D perception 7shifts

Cloud-AWS

Troubleshoot SigV4 signature mismatch errors with IAM authentication for API Gateway

How can I troubleshoot signature mismatch errors when making SigV4 signed requests with IAM authentication to API Gateway?

Last updated: 2022-09-22

The Signature Version 4 (SigV4) signed request to Amazon API Gateway failed with a 403 response and an error similar to the following:

"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method."

How can I troubleshoot this?

Short description

API Gateway API endpoints using AWS Identity and Access Management (IAM) authentication might return 403 errors if:

  • The API request isn't signed and the API request uses IAM authentication.
  • The IAM credentials used to sign the request are incorrect or don't have permissions to invoke the API.
  • The signature of the signed API request doesn't match the signature for the API Gateway API endpoint.
  • The API request header is incorrect.

Resolution

IAM authentication

Make sure that the API request using IAM authentication is signed with SigV4. If the API request isn't signed, then you might receive the following error: “Missing Authentication Token”

IAM credentials

Verify that the authentication credentials for the access key and secret key are correct. If the access key is incorrect, then you might receive the following error: "The security token included in the request is invalid."

Make sure that the IAM entity used to sign the request has execute-api:Invoke permissions. If the IAM entity doesn't have execute-api:Invoke permissions, then you might receive the following error: "User: arn:aws:iam::xxxxxxxxxxxx:user/username is not authorized to perform: execute-api:Invoke on resource"

Signature mismatch

If the secret access key is incorrect, then you might receive the following error: "The request signature we calculated does not match the signature you provided."

The secret access key must match the access key ID in the Credential parameter. For instructions, follow the Send a request to test the authentication settings section in How do I activate IAM authentication for API Gateway REST APIs?

Make sure that you followed the instructions for the SigV4 signing process. If any values in the signature calculation are incorrect, then you might receive the following error: "The request signature we calculated does not match the signature you provided."

When API Gateway receives a signed request, it recalculates the signature. If there are differences in the values, then API Gateway gets a different signature. Compare the canonical request and string to your signed request with the value in the error message. Modify the signing process if there are any differences.

Example canonical request: 

GET                                                      -------- HTTP method
/                                                        -------- Path. For API stage endpoint, it should be /{stage-name}/{resource-path}
                                                         -------- Query string key-value pair. Leave it blank if the request doesn't have any query string
content-type:application/json                            -------- header key-value pair. One header per line
host:0123456789.execute-api.us-east-1.amazonaws.com      -------- host and x-amz-data are required headers for all signed request                       
x-amz-date:20220806T024003Z                              

content-type;host;x-amz-date                             -------- A list of signed headers
d167e99c53f15b0c105101d468ae35a3dc9187839ca081095e340f3649a04501        -------- hash of the payload

Example canonical error response: 

<ErrorResponse xmlns="https://iam.amazonaws.com/doc/2010-05-08/">
  <Error>
    <Type>Sender</Type>
    <Code>SignatureDoesNotMatch</Code>
    <Message>The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

The canonical string for this request should have been 'GET / Action=ListGroupsForUser&MaxItems=100&UserName=Test&Version=2010-05-08&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential
=AKIAIOSFODNN7EXAMPLE%2F20120223%2Fus-east-1%2Fiam%2Faws4_request&X-Amz-Date=20120223T063000Z&X-Amz-SignedHeaders=host
host:iam.amazonaws.com

host
<hashed-value>'

The String-to-Sign should have been
'AWS4-HMAC-SHA256
20120223T063000Z
20120223/us-east-1/iam/aws4_request
<hashed-value>'
</Message>
  </Error>
  <RequestId>4ced6e96-5de8-11e1-aa78-a56908bdf8eb</RequestId>
</ErrorResponse>

Note: For API gateway headers, only the host and x-amz-date headers are required.

API request header

Make sure that the SigV4 authorization header includes the correct credential key similar to the following: 

Authorization: AWS4-HMAC-SHA256 
Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request, 
SignedHeaders=host;range;x-amz-date,
Signature=example-generated-signature

If the credential key is missing or incorrect, you might receive the following error: “Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter."

Make sure that the SigV4 authorization request also includes the request date using either HTTP Date or the x-amz-date header.

For more information, see Troubleshooting key signing errors and Troubleshooting AWS Signature Version 4 errors.

Examples of the complete Signature Version 4 signing process (Python)

How do I troubleshoot HTTP 403 errors from API Gateway?

Signing AWS requests with Signature Version 4

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support

Resolve "HTTP 403 Forbidden" errors when invoking API Gateway with an IAM cross-account

How can I resolve "HTTP 403 Forbidden" errors when invoking my API with cross-account IAM authentication for API Gateway?

Last updated: 2022-09-16

I called my Amazon API Gateway API with a cross-account AWS Identity and Access Management (IAM) entity (user or role). I get an "HTTP 403 Forbidden" error. How do I troubleshoot this?

Resolution

REST APIs

For accessing API Gateway REST APIs, turn on IAM authentication for an API method in the API Gateway console. Then, use IAM policies and resource policies to designate permissions for your API's users.

Make sure that the cross-account IAM entity has permissions to invoke the API and is allowed access in the resource policy.

In this example, the REST API for account A 111111111 has IAM authentication enabled. User1 tries to invoke from account B 999999999. User1 in account B has the following IAM policy attached: 

}
  ]
    }
      "Resource": "arn:aws:execute-api:us-east-1:111111111:AB12CDEF34/*/*/*"
      ],
        "execute-api:ManageConnections"
        "execute-api:Invoke",
      "Action": [
      "Effect": "Allow",
    {
  "Statement": [
  "Version": "2012-10-17",
{

To allow the IAM user for account B in account A to invoke cross-account access, use a resource policy similar to the following: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::999999999:user/User1"
      },
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:us-east-1:111111111:AB12CDEF34/stage/*/*"
    }
  ]
}

For more information, see How do I activate IAM authentication for API Gateway REST APIs?

HTTP APIs

For accessing API Gateway HTTP APIs, you can use the sts:AssumeRole API action to assume a role for the HTTP API account. The assumed role provides temporary security credentials that can be used to invoke the HTTP API in another account.

Make sure that the temporary security credentials used to invoke the HTTP API are correct and not expired.

For more information, see How can I provide cross-account IAM authorization for API Gateway HTTP APIs?

API Gateway resource policy examples

Activate IAM authentication for API Gateway Rest APIs

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

Resolve DNS or certificate mismatch errors for API Gateway custom domains

How can I resolve DNS resolution or SSL certificate mismatch errors for my API Gateway custom domain name?

Last updated: 2022-10-21

I configured a custom domain name for my Amazon API Gateway API. I am unable to connect to the domain name and receive DNS resolution or SSL certificate mismatch errors. How can I resolve this?

Short description

There are two types of custom domain names that you can create for API Gateway APIs: Regional or (for REST APIs only) edge-optimized.

Resolution

Before creating a custom domain name for your API, you must do one of the following:

Request an SSL/TLS certificate from AWS Certificate Manager (ACM).
-or-
Import an SSL/TLS certificate into ACM.

For more information, see Getting certificates ready in AWS Certificate Manager.

After you have your SSL/TLS certificate, you can follow the instructions to set up a custom domain name for my API Gateway API.

To connect to a custom domain name for API Gateway APIs, you must configure Amazon Route 53 to route traffic to an API Gateway endpoint.

If the DNS records for the custom domain name aren't mapped to the correct API Gateway domain name, then the SSL connection fails. This is because the default *.execute-api.<region>.amazonaws.com certificate is returned instead of the SSL/TLS certificate.

To confirm that the DNS mapping is correct, run the following command from the client: 

$ nslookup <customdomainname>

The output should be the API Gateway domain name. Make sure that the domain name matches the API Gateway domain name. If a Route 53 alias record is used for DNS mapping, then the output is the IP address. Make sure that the IP address matches the API Gateway domain name IP address.

Note:

  • When configuring Route 53, you must create either a public hosted zone or a private hosted zone. For internet-facing applications with resources that you want to make available to users, choose a public hosted zone. For more information, see Working with hosted zones.
  • Route 53 uses records to determine where traffic is routed for your domain. Alias records provide easier DNS queries to AWS resources, while CNAME (non-alias) records can redirect DNS queries outside of AWS resources. For more information, see Choosing between alias and non-alias records.

Migrating a custom domain name to a different API endpoint

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

Troubleshoot API Gateway 5xx errors

How can I troubleshoot 5xx errors for API Gateway?

Last updated: 2022-09-22

When I call my Amazon API Gateway API, I get an 5xx error. How do I troubleshoot API Gateway 5xx errors?

Short description

HTTP 5xx response codes indicate server errors. API Gateway 5xx errors include:

  • 500 internal server
  • 502 bad gateway
  • 503 service unavailable
  • 504 endpoint request timed out

Resolution

Before you begin, follow the steps to turn on Amazon CloudWatch Logs for troubleshooting API Gateway errors.

You can use the Amazon CloudWatch Logs to find 5xx errors from API Gateway. The API Gateway metric 5XXError counts the number of server-side errors captured in a given period.

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

500 error: internal server error

This error might be due to:

  • Errors in the AWS Lambda function code.
  • Missing permissions for using a stage variable.
  • Incorrect or missing HTTP status code mapping.
  • Throttling issues.
  • The HTTP method of POST isn't defined.
  • Lambda permissions.
  • Lambda function JSON format issue.
  • The backend payload size exceeded 10 MB.
  • Private endpoint integration.

Errors in the Lambda function code

API endpoints 500 errors that integrate with Lambda might indicate that the Lambda function has an error in the code. For more information and troubleshooting, see Error handling patterns in Amazon API Gateway and AWS Lambda.

Missing permissions for using a stage variable

If you set up an API Gateway to invoke an AWS Lambda function using a stage variable, you might receive an "internal server error". To resolve this error, see Why do I get an "Internal server error" and a 500 status code when I invoke the API method?

Incorrect or missing HTTP status code mapping

Incorrect or missing HTTP status code mapping can also result in 500 errors. To resolve this error, you can Set up mock integrations in API Gateway.

Throttling issues

If the backend service is throttled due to a high number of requests, the API Gateway API might return an "Internal server error". You can activate an exponential backoff and retry mechanism and try the request again. If the issue persists, check your API Gateway quota limit. If you exceeded the service quota limit, you can request a quota increase.

The HTTP method of POST isn't defined

For Lambda integration, you must use the HTTP method of POST for the integration request.

Update the method integration request using the AWS CLI command put-integration similar to the following: 

aws apigateway put-integration \
    --rest-api-id id \
    --resource-id id \
    --http-method ANY \
    --type AWS_PROXY \
    --integration-http-method POST \
    --uri arn:aws:apigateway:us-east-2:lambda:path//2015-03-31/functions/arn:aws:lambda:us-east-2:account_id:function:helloworld/invocations

Then, deploy the REST API using the AWS CLI command create-deployment similar to the following: 

aws apigateway create-deployment \
    --rest-api-id id \
    --stage-name <value>

Lambda permissions

Make sure that the integrated Lambda function or Lambda authorizers resource-based policy includes permissions for your API to invoke the function. Follow the instructions to update your Lambda function's resource-based policy.

Lambda function JSON format issue

The integrated Lambda function isn't returning output according to the predefined JSON format for REST APIs and HTTP APIs. Update your Lambda function or Lambda authorizer function JASON format similar to the following:

REST API 

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headerName": "headerValue", ... },
    "multiValueHeaders": { "headerName": ["headerValue", "headerValue2", ...], ... },
    "body": "..."
}

HTTP API 

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headername": "headervalue", ... },
    "multiValueHeaders": { "headername": ["headervalue", "headervalue2", ...], ... },
    "body": "..."
}

The backend payload size exceeded 10 MB

The maximum backend payload size is 10 MB and can't be increased. Make sure that the backend payload size doesn't exceed the 10 MB default quota.

Private endpoint integration

If you are using a private API endpoint, you must also configure API Gateway private integration. Follow the instructions to Set up API Gateway private integrations.

502 error: bad gateway

A 502 error code is related to the AWS service that your API Gateway integrates with such as an AWS Lambda function. API Gateway couldn’t process the response as a gateway or proxy.

To troubleshoot 502 error when integrated with a Lambda proxy function, see How do I resolve HTTP 502 errors from API Gateway REST APIs with Lambda proxy integration?

Note: API Gateway interprets the response from the backend service in a format that can be mapped in the integration response section using mapping templates. For more information, see Set up an integration response in API Gateway.

503 error: service unavailable

A 503 error code is related to the backend integration and the API Gateway API is unable to receive a response.

This error might occur if the backend server is:

  • Overloaded beyond capacity and is unable to process new client requests.
  • The backend server is under temporary maintenance.

To resolve this error, consider provisioning more resources to the backend server and activating an exponential backoff and retry mechanism on the client. Then, try the request again.

504 error: endpoint request timed out

If an integration request takes longer than your API Gateway REST API maximum integration timeout parameter, API Gateway returns an HTTP 504 status code.

To resolve this error, see How can I troubleshoot API HTTP 504 timeout errors with API Gateway?

Security best practices in Amazon API Gateway

Monitoring REST API execution with Amazon CloudWatch metrics

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

Connect API Gateway to your on-premises network

How can I connect to API Gateway from my on-premises network?

Last updated: 2022-08-31

I want to connect to Amazon API Gateway from my on-premises network. How can I do this?

Short description

API Gateway API types include REST APIs (edge-optimized and Regional API endpoints), HTTP APIs, WebSocket APIs, and private REST APIs. REST APIs, HTTP APIs, and WebSocket APIs can be connected from on-premises networks directly. Private REST APIs can only be accessed from within an Amazon Virtual Private Cloud (Amazon VPC) using an interface VPC endpoint.

Resolution

Before you begin, verify that your on-premises network:

  • has connectivity to the internet.
  • firewall allows bidirectional traffic to and from the API Gateway endpoint.

Connect an on-premises network to a REST API, HTTP API, or WebSocket API

Use invoke to connect your on-premises network to API Gateway depending on the API type.

For REST APIs, see Invoking a REST API in Amazon API Gateway.

For HTTP APIs, see Publishing HTTP APIs for customers to invoke.

For WebSocket APIs, see Use wscat to connect to a WebSocket API and send messages to it.

Connect an on-premises network to a private REST API

Private REST APIs can be accessed from within an Amazon VPC using an interface VPC endpoint. Use the following access methods depending on your configuration.

Note:

  • The security group for the interface endpoint must allow inbound traffic from your on-premises source CIDR range on TCP port 443.
  • The private API resource policy must be updated to allow private API traffic from the source VPC or VPC endpoint.

AWS Direct Connect

You can use Direct Connect to connect your on-premises network to Amazon VPC and access your private API using pubic DNS names. For more information, see Accessing your private API using Direct Connect.

Amazon Route 53 alias

Follow the steps to associate an Amazon VPC endpoint with a private REST API.

API Gateway then generates a new Route 53 ALIAS DNS record. You can use this record to invoke your private API in the following URL format: 

https://{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com/{stage}

For more information, see Accessing your private API using a Route 53 alias.

Private DNS names

If you are using private DNS, you can access your private API from your on-premises network using the private DNS names. You must set up a Route 53 Resolver inbound endpoint, and then forward to it all DNS queries of the private DNS from your on-premises network. For more information, see Invoking your private API using private DNS names.

Public DNS names

You can access your private API from your on-premises network using endpoint-specific DNS hostnames. The public DNS hostnames contain the VPC endpoint ID or API ID for your private API in the following URL format: 

https://{public-dns-hostname}.execute-api.{region}.vpce.amazonaws.com/{stage}

For more information, see Invoking your private API using endpoint-specific public DNS hostnames.

How do I access a private API Gateway API when the VPC endpoint uses an on-premises DNS?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article

Provide cross-account IAM authorization for API Gateway HTTP APIs

How can I provide cross-account IAM authorization for API Gateway HTTP APIs?

Last updated: 2022-08-31

I want to activate AWS Identity and Access Management (IAM) authentication for cross-account access to my Amazon API Gateway HTTP API. How do I set that up?

Short description

For API Gateway REST APIs, you can use resource policies to provide IAM authentication for cross-accounts. However, this option isn't available for API Gateway HTTP APIs.

You can use the sts:AssumeRole API action to assume a role for the HTTP API account. The assumed role provides temporary security credentials that can be used to invoke the HTTP API in another account.

Resolution

Create the IAM temporary credentials

Note: If you receive errors when running AWS Command Line Interface (AWS CLI) commands, make sure that you’re using the most recent AWS CLI version.

1.    Create an IAM policy for Account A that hosts the HTTP API. This policy provides invoke permission for the HTTP API execute-api ARN. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "execute-api:Invoke",
            ],
            "Resource": [
                "arn:aws:execute-api:us-east-1:<AccountA-id>:<Api-id>/$default/*/*"
            ]
        }
    ]
}

2.    Create an IAM role in Account A , add "Trusted Entity Type" as "AWS Account", and enter the ID for Account B .

3.    Attach the IAM policy created in step 1 to the IAM role created in step 2 .

4.    Create an IAM policy for Account B to allow the sts:AssumeRole API action: 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::<AccountA-id>:role/<AssumedRoleName>"
    }
  ]
}

5.    Attach the IAM policy to the user in Account B .

6.    Run the AWS CLI command assume-role similar to the following: 

$ aws sts assume-role --role-arn arn:aws:iam::<account-id>:role/<AssumedRoleName> --role-session-name role_session

Example output: 

{
    "Credentials": {
        "AccessKeyId": "A1B2C3D4E5E6G7H8J9K0",
        "SecretAccessKey": "abcdefghijk123456789",
       
 "SessionToken": 
"11111111111122222222223333333333344444444455555566666667777777777778888888999999999aaaaaaaaaabbbbbbbbbcccccccc==",
        "Expiration": "2022-07-11T15:55:25+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AAAAAAABBBBBBBBBBB:role_session",
        "Arn": "arn:aws:sts::<account-id>:assumed-role/<AssumedRoleName>/role_session"
    }
}

Check the credentials object for the AccessKeyId , SecretAccessKey , and SessionToken . These temporary credentials provided by the assumed role can be used to invoke the HTTP API.

Test the IAM authentication

Use the Postman app to send a request to your API resource using the method that you activated IAM authentication for.

Note: To manually authenticate requests that are sent to API Gateway using another tool or environment, use the Signature Version 4 (SigV4) signing process. For more information, see Signing AWS API requests.

1.    In Postman, choose the Authorization tab and do the following:
For Type , choose AWS Signature .
For AccessKey , SecretKey , and SessionToken , enter the values from the assume-role API call.

2.    For Enter request URL , enter your API's invoke URL similar to the following: 

https://<Api-id>.execute-api.<region>.amazonaws.com/<stagename>/<resourcepath>

An authenticated request returns a 200 OK response code. An unauthorized request returns the message Missing Authentication Token and a 403 Forbidden response code.

How do I activate IAM authentication for API Gateway REST APIs?

Did this article help?

Submit feedback

Do you need billing or technical support?

Contact AWS Support
Read article