1

Bluehost VPS running CentOS, but cat /etc/redhat-release reveals CloudLinux release 6.10 (Final).

Executing curl commands against Twilio APIs on my local PC (Win11/IIS/PHP) works fine. When I attempt the same thing on my Bluehost server (with verbose output enabled), it fails with this message:

certificate subject name '*.us-east-1.es.amazonaws.com' does not match target host name 'api.twilio.com'

* About to connect() to api.twilio.com port 443 (#0) * Trying 50.19.189.95... connected * Connected to api.twilio.com (50.19.189.95) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL: certificate subject name '*.us-east-1.es.amazonaws.com' does not match target host name 'api.twilio.com' * NSS error -12276 * Closing connection #0 curl: (51) SSL: certificate subject name '*.us-east-1.es.amazonaws.com' does not match target host name 'api.twilio.com'

Twilio support directed me to download their SSL cert through Chrome, which I did. I named the cert "cacert.pem", thinking that's what it needs to be named, but I have no idea. And here are the steps they had me perform in my bash terminal:

  1. Upload the cacert.pem File: First, upload the cacert.pem file to your CentOS VPS. You can use secure file transfer methods like SCP or SFTP for this.

  2. Determine the Certificate Store Location: The location of the certificate store may vary depending on the applications you want to use it with. For system-wide trust, you can typically place the certificate in /etc/pki/tls/certs/.

  3. Copy the Certificate File: Copy the cacert.pem file to the certificate store: sudo cp cacert.pem /etc/pki/tls/certs/

  4. Update the CA Certificate Bundle: To update the CA certificate bundle, run the following command: sudo update-ca-trust enable

  5. Refresh the CA Trust: Update the CA trust using the update-ca-trust extract command: sudo update-ca-trust extract

  6. Verify the Certificate Installation: You can verify that the certificate has been successfully installed by checking the CA bundle: cat /etc/pki/tls/certs/ca-bundle.crt The cacert.pem content should be included in this bundle.

  7. Restart Apache.

None of that made a difference and the wrong certificate is still presented.

I asked them "how does the OS know which certificate to use?" But they did not respond. Seems like that was never specified.

I ran a curl command (notice I use -k for insecure just to see what would happen) against Twilio API and got the following error:

Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter. Authorization header requires 'SignedHeaders' parameter. Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header. Authorization=Basic QUNmN***

I ran the 2 following dig diagnostics on the Bluehost server:

dig api.twilio.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.8 <<>> api.twilio.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58818 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;api.twilio.com. IN A

;; ANSWER SECTION: api.twilio.com. 20 IN CNAME
virginia.us1.api-lb.twilio.com. virginia.us1.api-lb.twilio.com. 20 IN CNAME self-healing.api-alb.us1.api-lb.twilio.com. self-healing.api-alb.us1.api-lb.twilio.com. 20 IN CNAME ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 34.204.146.75 ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 52.20.98.48 ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 35.153.214.247 ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 54.208.14.118 ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 54.242.5.138 ien-alb-bapi-b-156106065.us-east-1.elb.amazonaws.com. 20 IN A 34.232.251.189

;; Query time: 10 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Fri Nov 3 08:51:38 2023 ;; MSG SIZE rcvd: 260

dig api.twilio.com @8.8.8.8

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.8 <<>> api.twilio.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58143 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;api.twilio.com. IN A

;; ANSWER SECTION: api.twilio.com. 21 IN CNAME
virginia.us1.api-lb.twilio.com. virginia.us1.api-lb.twilio.com. 21 IN CNAME self-healing.api-alb.us1.api-lb.twilio.com. self-healing.api-alb.us1.api-lb.twilio.com. 21 IN CNAME ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 3.222.47.158 ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 34.236.63.82 ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 52.0.177.50 ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 34.232.27.126 ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 3.225.164.19 ien-alb-bapi-a-1963256146.us-east-1.elb.amazonaws.com. 21 IN A 52.206.184.52

;; Query time: 23 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Nov 3 08:52:11 2023 ;; MSG SIZE rcvd: 261

I tried the following on NOV-4 based on Turdie's suggestion:

curl -v --tlsv1.2 -X POST "https://api.twilio.com/2010-04-01/Accounts/ACf7b58ec793***4d/Messages.json" \ > --data-urlencode "Body=This is the ship that made the Kessel Run in fourteen parsecs?" \ > --data-urlencode "From=+14*****40" \ > --data-urlencode "To=+18*****44" \ > -u ACf7b*****30a4d:0ce7445d*****48bc4d

RESULT:

  • About to connect() to api.twilio.com port 443 (#0)
  • Trying 50.19.189.95... Timeout
  • Trying 35.168.202.10... Timeout
  • Trying 54.173.225.186... Timeout
  • Trying 107.22.7.7... Timeout
  • Trying 52.204.229.116... connected
  • Connected to api.twilio.com (52.204.229.116) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
  • SSL: certificate subject name '*.glympse.com' does not match target host name 'api.twilio.com'
  • NSS error -12276
  • Closing connection #0 curl: (51) SSL: certificate subject name '*.glympse.com' does not match target host name 'api.twilio.com'

I also tried the following on NOV-4 based on Turdie's suggestion:

openssl s_client -connect api.twilio.com

RESULT:

no port defined

(After that it spit out a ton of available args, like documentation. Not sure if you wanted that.)

I am a developer, but a novice with linux and certs, so I'm hoping someone can help me. Thanks in advance.

Improve this question
17
  • 2
    blog.cloudlinux.com/… ” CloudLinux OS 6 has officially reached its End-Of-Life on November 30, 2020” - Note with legacy software you might run into the issue that it does not implement SNI and you therefore don’t get the correct TLS certificate when you connect to a host that relies on SNI to present you the correct certificates (and the steps you took are irrelevant to address that) Commented Oct 26, 2023 at 18:31
  • 1
    You might want to check and see what happens when you use the curl -k insecure option to skip the validity check of the certificate Commented Oct 26, 2023 at 18:42
  • 3
    Those Twilio people are clearly insane; your problem has nothiing to do with the cert not validating against the truststore and no change to the truststore is needed, and if it were their method is almost entirely wrong. Your actual problem is that you aren't connecting to api.twilio.com at all. 50.19.189.95 is not an address for that domain -- see dnschecker.org/#A/api.twilio.com -- and it actually connects to some different and wrong host, albeit also in amazon us-east-1. Check the name resolution being used on your server, probably but not necessarily DNS. Commented Oct 27, 2023 at 2:34
  • 1
    @HBruijn: in general possibly, but in this case the real api.twilio.com hosts give the same cert with or without SNI and and 50.19.189.95 gives a different cert but also the same with or without SNI -- and the cert from 50.19.189.95 isn't for twilio because 50.19.189.95 is not twilio at all. Commented Oct 27, 2023 at 2:37
  • 1
    Worth noting that all of the IP addresses returned from the dig command run on the Bluehost, and the original IP address, all present the correct Twilio certificate when queried by VirusTotal. Commented Nov 4, 2023 at 14:44

1 Answer 1

Reset to default
0

Based on my research this is an issue with curl.

You need to use curl -v --tlsv1.2

This looks like a similar issue as the TS is experiencing

https://blog.michaelfmcnamara.com/2015/12/curl-and-ssl-tls-issues/

It seems like in your curl, you are sending a certificate with the glympse.com NSS with certpath: sql:/etc/pki/nssdb. That causes a mismatch because twilio.com and glympse is a different name. I think you need to check with twilio.com which certificate you need to use to connect to the api. It also looks like your are using nssdb and a sql database, i dont have any knowledge of that.

The last line in the curl clearly states the certificate mismatch Closing connection #0 curl: (51) SSL: certificate subject name '*.glympse.com' does not match target host name 'api.twilio.com'

Edit

Where is your api key in this? Check the docs

curl -v --tlsv1.2 -X POST "https://api.twilio.com/2010-04-01/Accounts/ACf7b58ec793***4d/Messages.json" \ > --data-urlencode "Body=This is the ship that made the Kessel Run in fourteen parsecs?" \ > --data-urlencode "From=+14*****40" \ > --data-urlencode "To=+18*****44" \ > -u ACf7b*****30a4d:0ce7445d****
Improve this answer
9
  • Turdie, thank you. What you suggested didn't fully work, but this seems MUCH CLOSER than I have ever gotten before. No SMS was sent, but the results are promising. I posted the entire results up on my original post. Any ideas how I can take this across the finish line? Commented Nov 4, 2023 at 16:26
  • Sorry I forgot the port, it should be openssl s_client -connect api.twilio.com:443. For the rest see the edits. Commented Nov 4, 2023 at 17:03
  • I tried your latest with the port and it just prompts me with a cursor. No idea what to enter now, and I don't know what you mean by For the rest see the edits. Commented Nov 4, 2023 at 17:14
  • Try this in curl : To ignore invalid and self-signed certificate checks on Curl, use the -k or --insecure command-line option Commented Nov 4, 2023 at 17:15
  • The -k- didn't make any difference, though the result messages were a little different. Commented Nov 4, 2023 at 22:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.