问题
The php system I am supporting posts data to an SMS gateway to send SMS messages. It successfully posts the data over 99% of the time. Very occasionally it will fail with the curl error SSL: no alternative certificate subject name matches target host name 'api.twilio.com'.
This can happen in the middle of sending dozens of SMS messages, several will post and get sent, one or two will fail and then the rest will post successfully. I have discussed this error with the SMS gateway provider (Twilio) but they weren't particularly helpful. As I learned more about the issue I realized that this is not really their problem (unless I can show that they have issues with their SSL certificates).
I have learned a great deal about the curl options CURLOPT_SSL_VERIFYHOST, CURLOPT_SSL_VERIFYPEER and CURLOPT_CAINFO.
I tried downloading the most recent cacert.pem from https://curl.haxx.se/ca/cacert.pem and pointed to it using CURLOPT_CAINFO. This did not resolve the problem. I have since removed the CURLOPT_CAINFO option.
This morning, I temporarily set both CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER to '0'. I understand that this puts my posted data at risk but I need to at least show that this will resolve my problem.
During my research, I was advised to do a nslookup on the Twilio api. The results are below
MacBook-Air-2:~ Jon$ nslookup api.twilio.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
api.twilio.com canonical name = virginia.us1.api-lb.twilio.com.
virginia.us1.api-lb.twilio.coM canonical name = nlb-api-public-c3207ffe0810c880.elb.us-east-1.amazonaws.com.
Name: nlb-api-public-c3207ffe0810c880.elb.us-east-1.amazonaws.com
Address: 18.211.224.155
Name: nlb-api-public-c3207ffe0810c880.elb.us-east-1.amazonaws.com
Address: 18.208.54.140
Name: nlb-api-public-c3207ffe0810c880.elb.us-east-1.amazonaws.com
Address: 18.212.47.248
Is this a problem? should there be 3 addresses for the api?
I have also been advised to rebuild the PHP curl package. This will be my next step unless anyone can suggest something else that I should try first.
Given that the error is intermittent, I can only assume that the curl function is finding different Twilio apis, or different SSL certificates each time it creates a connection. Is this a valid assumption?
My question(s) is simply, What is my next best action? What else can I try? Should I be putting more pressure on Twilio, or my hosting service (iPage) to help me?
Update 7/1/2020
After setting the verifyhost and verifypeer options to '0' and monitoring for the last 48 hours, I am no longer seeing any certificate errors, which would seem logical. However, I am still experiencing the occasional SMS message not being sent (I'm just not getting any errors reported - and Twilio has no record of any attempt to send an SMS from my account). This suggests to me that I am attempting to connect to a third party that is attempting a man-in-the-middle attack, maybe?
I'm really getting out of my depth here, so I am open to any suggestions as to what to do next.
Update 7/6/2020
I added some code to capture the curl data and write to a log when the curl SSL fails.
When the curl fails, it is attempting to connect to 66.96.147.96 which points to an ipage server. The certificate is *.ipage.com. Twilio have verified that this is not a valid ip address for their api. This explains why my SSL verify is failing. Keep in mind that ipage provides the hosting service for this system, which is surely more than just a coincidence.
My assumption at this point is that I am getting a bad ip address from an ipage DNS server when trying to resolve api.twilio.com. I will open a ticket with ipage and see what they have to say about this.
Update 7/7/2020
After playing around with NSLOOKUP on my ipage VPS server I think I may have found the issue. My VPS (hosted by ipage) points to an ipage DNS server at 74.220.195.27. If this DNS server is presented with an unknown url (NXDOMAIN) or times out, it appends ipage.com to the request and returns 66.96.147.96 which is an ipage website. (I think this behavior is designed to direct lost traffic to ipage under the guise of displaying search results). I think my curl request occasionally times out when attempting to resolve the url api.twilio.com and then attempts to connect to 66.96.147.96 at which point the SSL verify fails. Furthermore, this ip address is saved in the curl DNS cache which is why I often see several fails in sequence before the situation resolves. I have set the curl option CURLOPT_DNS_CACHE_TIMEOUT to zero to see if this helps reduce the problem.
I currently have a ticket open with ipage to see if I can change my default DNS server (there is no resolv.conf file for me to edit - how is my DNS server configured?).
来源：https://stackoverflow.com/questions/62643529/intermittent-curl-error-when-posting-to-sms-gateway-bad-dns-record