CURL POST issues with Let's Encrypt


#1

My domain is: DailyDigitalNews.com
Codero Hosting with Plesk.
cURL seemingly enabled.

We’ve encountered an issue whereby cURL POST fails when trying to access the IBM Watson API via a php sdk that relies on cURL:

i.e
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data, JSON_UNESCAPED_UNICODE));
curl_setopt($ch, CURLOPT_USERPWD, $username . ‘:’ . $password);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

Testing the exact same code/app on other servers is working fine, and SSL is believed to be the culprit.
our PHP settings (that don’t work)
https://imgur.com/vpFL8wD

View post on imgur.com

working PHP settings (that do work)
https://imgur.com/TRfUBs0

View post on imgur.com

Is this a known issue, what’s causing it, and what work arounds are there?
Thanks in advance for your help.


#2

Hi @jsbullock9,

Can you give examples of the exact URLs that do and don’t work with the POST command? Or is the idea that it’s the same API endpoint on another server and your two different clients don’t exhibit the same behavior?

Also, what is the error returned by the cURL library?

Can you try testing with the command line curl -v instead of just with the PHP cURL library? It uses the same underlying code base, but you’ll see the error messages right away in diagnostic output.


#3

Hi Schoen,
Thanks for the very quick response. Loved how easy it was to setup let’s encrypt with codero/plesk by the way!

Its the same API endpoint all the time.
Running the cURL -v with the required API endpoint url returns the following:

curl -v https://gateway.watsonplatform.net/natural-language-understanding/api/v1
* About to connect() to gateway.watsonplatform.net port 443 (#0)
*   Trying 23.204.7.158...
* Connected to gateway.watsonplatform.net (23.204.7.158) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12190 (SSL_ERROR_PROTOCOL_VERSION_ALERT)
* Peer reports incompatible or unsupported protocol version.
* Error in TLS handshake, trying SSLv3...
> GET /natural-language-understanding/api/v1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: gateway.watsonplatform.net
> Accept: */*
> 
* Connection died, retrying a fresh connect
* Closing connection 0
* Issue another request to this URL: 'https://gateway.watsonplatform.net/natural-language-understanding/api/v1'
* About to connect() to gateway.watsonplatform.net port 443 (#1)
*   Trying 23.204.7.158...
* Connected to gateway.watsonplatform.net (23.204.7.158) port 443 (#1)
* TLS disabled due to previous handshake failure
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Closing connection 1
curl: (35) Peer reports incompatible or unsupported protocol version.

#4

This problem is not related to your Let’s Encrypt certificate.

Rather, the server you are trying to connect to (gateway.watsonplatform.net) only supports TLS version 1.2.

If I’m reading this correctly, curl 7.29 might not support TLS 1.2 when used with NSS.

Are you able to upgrade to a more recent curl version?


#5

Interesting!

I don’t think there is any connection with Let’s Encrypt at all—it’s just a coincidence that your own site is using a Let’s Encrypt certificate. But your Let’s Encrypt certificate isn’t involved in this failed negotiation in any way, because it’s only used to secure inbound connections to your web site from elsewhere, not outbound connections from your site to the Watson API.

So, I would suggest asking on a cURL or TLS-related forum (maybe on Server Fault if you don’t know of somewhere more specific). There might be a straightforward way to change your copy of cURL’s libraries. It will be more on-topic somewhere else and you might find a larger community of people who’ll be prepared to debug the problem.

Edit: or if there’s a forum for the Watson API service itself, that would be even more relevant. :slight_smile:


#6

Okay brilliant. That’s Let’s Encrypt ticked off.
Didn’t want to believe Let’s Encrypt was the problem.

Thanks @jmorahan and @schoen for the assistance and will look at cURL updating etc.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.