API Gateway General SSLEngine error

API Gateway General SSLEngine error is a common error in the API Gateway private integration (VPC Link) and HTTP Integration. In both these integrations the endpoint can be HTTPS and as a requirement the backend target must return a certificate trusted by certificate authorities supported by API Gateway. Here is a list of certificate authorities supported by API Gateway for HTTP endpoints [1]

API Gateway General SSLEngine error can be observed in following scenarios, when Integration returns :

  1. A certificate signed by issuers API gateway do not trust [1]
  2. An expired certificate
  3. A self-signed certificate [2]
  4. Certificate signing chain/chain of trust is missing the root certificate or one or more intermediate certificates [2]
  5. Any other unrecognizable certificate-related exceptions [2]
HTTP PROXY/NON-PROXY INTEGRATION

For HTTP integration, the request flow looks like

client ----> API Gateway ----> Public HTTP Endpoint Backend

In this case, the backend target where the TLS termination occurs must comply with the above stated requirements.

PRIVATE INTEGRATION

For private integration, the request flow looks like

client ----> API Gateway ----> NLB (Network Load Balancer) ----> Backend

A Network Load Balancer can have either a TLS or a TCP listener which would determine whether the TLS termination would be on Network Load Balancer or the Backend targets behind Network Load Balancer.

When Network Load Balancer has a TLS listener, TLS termination will be on Network Load Balancer and Network Load Balancer will be making a new connection with backend target. Certificate associated with TLS listener must comply with the requirements stated above. Once the TLS termination between API Gateway <——> NLB is completed, you may choose to have a TCP or TLS target. A new connection between NLB <——-> Target would be made. If a target group is configured with the TLS protocol, the network load balancer establishes TLS connections with the targets using certificates that you install on the targets. The load balancer does not validate these certificates. Therefore, you can use self-signed certificates or certificates that have expired. Because the load balancer is in a virtual private cloud (VPC), traffic between the load balancer and the targets is authenticated at the packet level, so it is not at risk of man-in-the-middle attacks or spoofing even if the certificates on the targets are not valid. [3]

When Network Load Balancer has a TCP listener, then TLS handshake happens directly with the backend target . In this scenario, backend target instance would be responsible to present with a certificate which complies to above stated requirements.

API Gateway and Network Load Balancer now support multiple TLS certificates using Server Name Indication (SNI). Based on the host name provided in the Endpoint URI in integration request, a certificate with matching name is returned by network load balancer [4]

If you have any questions related toIf you have any questions related to articles on this website please free to ask in our CloudNamaste discord channel – https://cloudnamaste.com/join-cloudnamaste-discord-community/

Join here directly : https://discord.gg/TEbhdutUDQ

I hope this article helps 🙂 Happy Troubleshooting !!

References:
[1] API Gateway supported certificate authorities for HTTP endpoints
[2] API Gateway Known REST API issues
[3] Network Load Balancer
[4] Announcement : Network Load Balancer supports SNI