1

I've been working with an API for some time now with which calls work for the majority of the time however occasionally (1 to 2 times a day for around an hour, although it's completely unpredictable when and how long for!) I get the following error message:

"An error has occurred: SSL: no alternative certificate subject name matches target host name 'api.xxxxx.com'"

I've been monitoring the api both with scheduled calls from my server and externally using runscope and also manually with Postman. When my server calls have the issue runscope and Postman do not suggesting it's a problem on my side.

FYI I'm querying the api from a linux server using PHP to run basic authentication with both file_get_contents and Curl - both approaches display the same issue.

Having worked with the super helpful api owner dev team it appears that, upon using the openssl command:

echo | openssl s_client -showcerts -servername api.XXXXX.com -connect api.XXXXX.com:443 2>/dev/null | openssl x509 -inform pem -noout -text

my server is somehow pointing the api's domain to my own, i.e. this command outputs my own ssl certificate and not that of the api.

Does anyone know how to fix this and/or stop this happening again?

  • 1
    The most obvious cause is that the service is running on multiple servers but with different configs/certificates. Do you know if the API runs on a single server or multiples? Why not set up a job to poll the api certificate periodically and see if its changing. – symcbean Apr 18 '16 at 14:52
0

a subject alternative name is a way of using one certificate for multiple virtual hosts - you are essentially getting a name mismatch error when connecting to the server, at some point you are connecting to a secure URL that the certificate knows nothing about, paste all of your API endpoint urls into this checker https://www.digicert.com/help/

if you have an api myapi.example.com and a signed certificate you can't make secure calls to myotherapi.example.com unless you have stated myotherapi.example.com as a subject alternative name or you have a wildcard certificate.

the fact that it only does this once a day could be down to load balancing, if you have 2 or more servers in a load balanced pool make sure that the SSL off loading is applied to both servers - otherwise the load balancer may direct you occasionally to a host with a self signed certificate (if you have encrypted the channel between your load balancer and your hosts) - if the servers are load balanced and SSL is off loaded for both servers correctly - then make sure there apache ServerName is exactly the same i.e. not api1.example.com and api2.example.com

lastly make sure you only have one DNS entry pointing to the load balancers virtual IP

  • Thanks for the input rob however I have a wildcard certificate and am not using a load balancer, this is a simple 1 dedicated server setup. As you can see I've now updated the question to hone in more specifically on the issue. – user1419810 Apr 19 '16 at 10:44
  • the only way this could be happening is is api.XXXXXX.com is being redirected - is there any difference between "ping api.XXXXX.com" and "nslookup api.XXXXX.com" – Sum1sAdmin Apr 19 '16 at 11:05
  • Nope, no difference, both output the same ip – user1419810 Apr 19 '16 at 11:11
  • then it must be curl - can you try editing some of the curl options particularly test changing follow location to false if it is true CURLOPT_FOLLOWLOCATION => false – Sum1sAdmin Apr 19 '16 at 11:42
  • No, i don't think it's CURL I've tried using both file_get_contents and CURL and both fail (both also tried separately.) Besides, as described with the question update, isn't this an OpenSSL issue? What I'm trying to find out is why my server is intermittently pointing the api's domain to my own? – user1419810 Apr 19 '16 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.