Proxy calls to SSL endpoint via AWS API Gateway

Question

Currently my apis are accessible over an SSL endpoint. I tried to configure aws api gateway to proxy requests to my endpoint.

I have enabled input pass through and set application/json as the content-type.

In any case, when i try a test request on aws web interface, with a GET method to a SSL url that looks like this https://subdomain.domain.com/v1/resource , i get the following error.

Execution log for request test-request
Thu Aug 06 06:55:27 UTC 2015 : Starting execution for request: test-invoke-request
Thu Aug 06 06:55:27 UTC 2015 : API Key: test-invoke-api-key
Thu Aug 06 06:55:27 UTC 2015 : Method request path: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request query string: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request headers: {}
Thu Aug 06 06:55:27 UTC 2015 : Method request body before transformations: null
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request URI: https://xyz.domain.com/v1/resource
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request headers: {Accept=application/json, User-Agent=AmazonAPIGateway_6cb3krv5t9}
Thu Aug 06 06:55:27 UTC 2015 : Endpoint request body after transformations: 
Thu Aug 06 06:55:27 UTC 2015 : Execution failed due to configuration error: handshake alert: unrecognized_name

What am i missing with SSL certificates?

Any help or clues are appreciated.

Answer 1

I think the answer to this is a somewhat subtle misconfiguration of your web server, that browsers may tend to ignore, but that Java (in the AWS infrastructure) does not.

The question isn't exactly a duplicate of SSL handshake alert: unrecognized_name error since upgrade to Java 1.7.0 since it is occurring in an different (from your perspective) environment... but I believe that question explains what you are seeing.

Modern TLS (SSL) stacks have a feature that provides a solution to an age-old problem: in HTTP over SSL (HTTPS), the SSL negotiation of necessity takes place before the request headers, including the Host: header, are sent... and only one SSL certificate can be offered to the client. Prior to the introduction of the Server Name Identification (SNI) extension, this essentially meant you were limited to 1 SSL certificate per public IP address on your server, and so if you had multiple domains with separate SSL certificates, you had to have a public IP address for each certificate, so that the web server would offer up the correct certificate for the domain name, because the certificates were bound to the IP address in server config.

Now, at least for modern browsers, SNI allows the browser to give the server a hint as to the hostname it's going to be making a request for, before the server sends a certificate... which might be one of several, for different domains. This eliminates the old and wasteful practice of one static IP per cert, since it allows multiple certs to be configured behind just one IP address where the server is listening.

The client (the API Gateway's "outbound" component connecting to you, in this case) "talks first" in TLS negotiation, and the SNI is in the first message. If the server understands the message construction, but isn't expecting to see that particular hostname, is is supposed to throw back a fatal error, but it can also send only a warning message.

That message, which presumably is a warning, seems to look a lot like what you are seeing in the log. If the Java TLS implementation is being strict, and your server is misconfigured in this way (not recognizing the hostname in the context of SNI, and sending a warning instead of an error), then I would expect exactly this behavior, even though other clients (user agent libraries and browsers) may just continue the SSL negotiation without apparent error, "forgiving" the warning-level alert if the certificate the server offers by default is indeed valid and matches the domain.

If I have pieced this puzzle together correctly, you should be able to confirm this behavior with a packet sniffer like tshark, and correct your web server's behavior accordingly.

Answer 2

This seems like a very specific question for someone on the API Gateway team. Community here can't really help you with this. Try contacting AWS via API Gateway section on AWS Forums.