1

I have an api gateway setup. It has a custom domain name setup on a regional endpoint and is using a certificate in ACM. I am able to make successful requests to the custom name from my local machine and even with curl from the remote machine I'm attempting to use. However, from the java application running on the remote machine I see this

! javax.net.ssl.SSLException: hostname in certificate didn't match: <my.custom.domain.name.com> != <*.execute-api.us-east-1.amazonaws.com> OR <*.execute-api.us-east-1.amazonaws.com>

I have a route53 alias record pointing to the target domain name of the custom domain name endpoint configuration.

Any idea how to resolve this without just removing host checking from the java application.

feanor114
  • 85
  • 3
  • 12
  • 1
    Based on the error, it looks like the back end return the certificate for the domain name "*.execute-api.us-east-1.amazonaws.com". Most probably this is due to some issue with the Route53 config (just guessing at the moment). 1. Can you post the verbose output (curl -vvv) of the successful request/response? 2. Also are you using CNAME alias record or A Alias record to point your custom domain name to the target endpoint config? 3. What is the target endpoint you have configured in the Route53 (does it start with d-..., OR the api endpoint such as abcd123.execute-api.....)? – Denis Weerasiri Feb 23 '19 at 00:47
  • 4
    Another possible cause would be the Java HTTPS code being old enough that it doesn't properly send server name identification (SNI). From a command prompt try `true | openssl s_client -connect custom.example.com:443 -showcerts | openssl x509 -text -noout` If you get the `*.execute-api` certificate, repeat the command exactly the same, but with `-servername custom.example.com` added before `-showcerts`. Otherwise, repeat with `-noservername` before `-showcerts`. If you can trigger the cert to change from one to the other like this, you have an issue with SNI rather than DNS. – Michael - sqlbot Feb 23 '19 at 07:54
  • @Michael-sqlbot I think you may be right was able to trigger the cert to change with those commands. I found the java application is currently using java version 1.7.0_201 though. From some quick searches I've so far only seen that SNI issue mentioned related to some older versions of java 8 not 7 though. Do you know if that issue was also in java 7? Either way the test you provided seems to indicate the SNI issue. – feanor114 Feb 25 '19 at 14:32
  • @feanor114 I'm not sure about Java. [This](https://stackoverflow.com/a/14884941/1695906) *seems* to indicate that it's present in 7 and should be enabled by default, which is not exactly what I was hoping to see... but if you actually saw the cert on the custom.example.com endpoint change from custom.example.com back to execute-api based on how you used (or omitted) `-[no]servername`, then that seems like a really compelling indicator that you are getting the wrong cert because SNI is not enabled on the client code, so API Gateway returns a generic default certificate. – Michael - sqlbot Feb 25 '19 at 15:10
  • @Michael-sqlbot updating the Java version resolved the issue. Thank you for your help – feanor114 Feb 27 '19 at 14:49

1 Answers1

0

I was exactly in the same situation, and I changed my Route53 record routing to the API endpoint from CNAME to A (by following the AWS documentation), and that solved the issue.

Romain Spinelli
  • 185
  • 5